Lean-Agile Partners - Lean-Agile Partners Blog

Spreading Mob Programming

Sat, 06 Jun 2015 05:55:55 GMT

by Nancy V.
About 6 months ago, I visited Bluefruit Software. To help them accelerate the learning for team leads, I introduced two teams to Mob Programming. (See www.mobprogramming.com) A few weeks later, they blogged about it here http://www.bluefruit.co.uk/training/mob-programming-nancy-van-schooenderwoert/

(Above) A team at Bluefruit in their first Mob Programming experience.

There are a lot of remarkable things about Mob Programming, and sheer contagion is top of the list for me! With no prodding from me, they immediately started to use it for some aspects of their work. No one pressured them to use it - not me, not their mangers. I suspect that is part of the reason it got adopted there; they could own it.

In eXtreme Programming there's a saying "The simplest thing that could possibly work". I think of Mob Programming as the craziest thing that could possibly work:-) A whole team at one computer; everyone thinking and conversing about the work at hand while one does the keyboarding. To see what this looks like, check out the 3-minute video at https://www.youtube.com/watch?v=p_pvslS4gEI

The Unrecoverables

Wed, 13 Aug 2014 17:38:24 GMT

       Time, Revenue and (Almost) Marketshare
            Mark Taylor, Collaborator, Lean-Agile Business Practice

    In every type of business there are three areas where missed opportunity can never be recovered: sunk time, missed revenue, and - nearly always - lost marketshare.

    Simple math:
(Expected average selling price X Number of expected units/month) X The number of months over planned launch date = Unrecoverable revenue.

    Add to that the delay in launching the next product or enhancement because resources were needed to finish the last over schedule project and the unrecoverable time and revenue loss just gets bigger. Oh, and let’s not forget marketshare loss. Lost marketshare can be recovered, but at significant cost; and the resources spent there detract from market growth efforts.

What to do? Here’s a few to-do’s that have worked for me.
1. ID and eliminate bottlenecks
    a. SW<>HW
    b. Dev<> QA
    c. Market requirements<>Dev
2. ID and remedy malfunctions
    a. Marketing, “That’s not what I asked for.” Development,         “That’s what your M/PRD said.”
    b. “We’ll let selected customs see it at beta test.”
    c. “You heard about WHAT 2 months ago!?!”
3. ID and resolve behavioral Issues
    a. It’s all their fault
    b. This is the way we’ve always done it
    c. It’s all about me
    d. “Yes I can do that, yes I have the time, yes I know it’s             next in the backlog, but no one told me to do it.”

What have been your avoid-the-unrecoverables to-do list?

Get Lost - Not

Mon, 11 Aug 2014 18:31:00 GMT

Mark Taylor, Collaborator, Lean-Agile Business Practice

There are two spots where products in development most often lose their way. In the first mile because the
initial wave of requirements are 1) vague, 2) context-less, and 3) not from a representative market sample.
The next where-am-I point, the last mile, is where the DONE target keeps moving, often because of unrelated events; for example, a competitor’s product announcement, an individual customer’s last minute demand, and
a product manager’s launch remorse.

The First Mile
Vague requirements frequently happen for 2 reasons
    1. A business unit can’t keep up with the requirements pull from a high velocity Lean-Agile development silo and, dare I say, make things up.
    2.   Requirements come to the development team as a feature list rather than a context sensitive story.
    Silos of any kind are a precursor to a train derailment if not a full wreck. This holds true for a Lean-Agile software team silo. The best starting point for a Lean-Agile initiative is with a product team that includes all the functions needed to take a new offering or enhancement from the defined and validated market pull through to launch and life cycle management.
    That being said, the vast majority of Agile initiatives start with the software team; and those well managed see, for a time, significant improvements. Then the Agile software silo runs into the rest of the non-agile organization and stalls. Hardware teams can’t synch up, marketing can’t deliver context- validated requirements fast enough and release operations can’t handle the volume of ready-to-go offerings delivered to their doorstep.
    We’ll address the hardware and release operations chasms in a separate article.
    In the current age of “I know what I want and I want it now” the defined and validated requirements gathering process needs to be done in a continuous, synchronous flow. Continuous because the elements that affect the market condition change weekly, yes weekly. Synchronous because, at that rate of change, the other product team members need to know about changes ASAP to avoid going too far down a path that will need to be backed out of.
    Why is context important? The “Here’s the features, build it and they will come” mantra actually never worked. Numerous studies have shown that as much as 60% of product features are not used. Rather than ask a representative sample customer “What do you want?” ask, “Tell me about your day, week, month, quarter.” That way you find out not only what they want, but also how it will be used in different contexts.
    Who do you interview: the user, chooser and approver? Why? Context. The user is at the desktop, the chooser, usually a manager, is concerned with team and tool collaboration, and the approver holds the budget. Miss any one of these stakeholders and you have a three leg stool with only 2 legs.

The Last Mile
As the launch date approaches and the ‘product done’ target is in sight several choke points arise. The ones I’ve see most often are:
    1.   Competitor’s announcements
    2.   An individual customers demands
    3.   The product manager’s selected launch date remorse.

    A knee jerk reaction to a competitor’s product announcement is often context-less and rarely justified. Properly selected sample customers as part of the product team and effective interview techniques tell you not only what they want, but also what the competition has told them about what is coming. This is not a violation of confidentiality but just an understanding of how an interviewee answers questions based on need vs. something they’ve been told.
    Things to ask your customer product team member about a competitive announcement:
    1.   Does it address the user, chooser and approver
    2.   Cost of change

    An individual customer’s last minute demand is not a launch stopper in a Lean-Agile product team. Why – continuous, synchronous requirements gathering process. A continuously sampled customer’s last minute demand is always, yes always either a corner case or a knee jerk reaction of their own because of unanticipated changes in their target market conditions. Bringing that demand to the customer’s product team members (user, chooser and approver) usually moves it to the ‘next release’ list.
    Every product manager for all time has a moment of doubt at launch time. Keeping it to a moment rather than a straightjacket and sedative event is the key. Continuously validating and verifying the product value with customers, channels of distribution, sales, and outbound marketing keeps the remorse to a moment.

Conclusion
Continuous verification and validation of product value with sample customers and market conditions along with synchronous communication with cross function product team members ensures a better quality, faster delivery, and lower cost solution.

Agile Engineering Program announced

Tue, 13 May 2014 04:43:29 GMT

by Nancy V.

For several years I've been meeting engineers who are finding truly interesting ways to do flexible product development despite the constraints of circuitry, or mechanical components, etc. Sometimes they are taking a cue from Agile software teams they work with, but just as often they're simply doing what good engineers have always done - take advantage of modular designs, do concurrent experiments to maximize learning, or just build a handy test jig.

I kept on wondering what would emerge if these folks could all see each other's ideas - sort of the way a dance company can all see the whole group in the mirror, and that enables them to cooperate in new ways.

So that is the essence of this "Agile Engineering" program that I proposed to the Agile Alliance. We'll just make it simple for people to create brief 1 or 2 page descriptions of techniques they're using. You can see examples here
http://www.agilealliance.org/programs/agile-engineering-program/

As the set of content grows, we will categorize it and make it simple to browse - and to connect with people working on the same problems.

I invited Neil Johnson to help with this because his hardware background is different from mine, and because pairing is good;-) He tweets as @nosnhojn, and I'm on as @vanschoo. We are using twitter a lot to publicize this, and it will be mentioned in the Agile Alliance newsletter.

You can help by
- Contributing your Agile Engineering tips
- Point your colleagues to the Agile Engineering site: http://www.agilealliance.org/programs/agile-engineering-program/
- Give us your comments -- tweet, blog, post about it

Thanks!

Two Enterprise Engines Help Keep Stakeholders Engaged and Active

Wed, 29 Jan 2014 20:11:46 GMT

The goal of just the right product or program, at just the right time requires continuous, synchronous communication among internal stakeholders and selected customers. Two enterprise engines, well maintained and continuously running, are key success factors in achieving this goal: The inside-out and the outside-in engines.

The inside-out engine is the product or program lifecycle. Even with only a handful of offering each will have its own lifecycle with hold ‘em or fold ‘em decision for each.

Whether it’s a new product in development or existing offering due for enhancements, or marketing, sales, manufacturing or finance project or program all have a lifecycle. On any given day at any hour members of different functional groups in an enterprise are asked to contribute to a product or program at some stage of it’s lifecycle. Keeping stakeholders current on your project so they can keep you informed on any changes in their area affecting your efforts helps keep course-corrections manageable.

The outside-in engine is the MCPESTEL engine. MC who? Market, Competition, Political, Economic, Social, Technology, Environmental, and Legislative/Legal are segments that different members of your enterprise watch, and that’s a good thing. On average every 8 days something of significance to your project changes among these segments. Stakeholders keeping you informed about changes in their purviews also keep changes in course small and manageable.

Whether it’s the MCPESTEL engine speeding along or the only slightly less speedy Product/Program Lifecycle engine stakeholders across the enterprise and selected customers see the benefit of continuous, synchronous communication to ensure the right product/program at just the right time.

Iterative Development Works for Embedded Systems Engineering

Fri, 20 Dec 2013 19:40:08 GMT

I’m interested in Agile methods for engineering work, including safety-critical applications. Some say iterative development is not practical where hardware is involved, and not wise for safety-critical products such as infusion pumps or pacemakers. I have a different view. - Nancy V.

Agile Iterative Development mitigates risk

Agile thinking is all about risk and how to mitigate it. Iteration is the primary risk mitigation strategy in Agile work. Regularly delivering tested, working features is the way we avoid having built components that cannot work together.

Figure 1. Delivering Projects in Component Layers

But engineers are used to building products in component layers. It seems more efficient to focus on completing each component, from the lowest level hardware on up through firmware and application software layers. The problem is that there are always enough unknowns in development to make that a risky strategy. It’s risky because building a system this way means that most of the features cannot be exercised until late in the project. If we discover then that our customer’s needs have shifted, or that we misunderstood what they really need – there just isn’t much maneuvering room left!

All traditional projects run the risk that sub-systems won’t work after they’re put together in the integration phase of the project. Agile teams successfully deal with this by continuous integration – fully integrating each new feature as it’s completed. There is no big-bang integration phase to go wrong.

So far I’ve only talked about process risk. There is also product risk – the risk that some other device might mess with your implanted pacemaker, for example. I’ll address that risk too in this blog, but a solid product has to come from a solid process. How you get there matters. So first I want to discuss process risk in embedded systems work.

Staying in control of the work is paramount. For me, that has always meant being able to slice up the work and make the progress visible. What ways have you used to keep your work on target?

Nancy Van Schooenderwoert