Skip to content


What’s Down With Agile Documentation?

Agile Management Blog - VersionOne - Wed, 07/30/2014 - 17:56

Guest post by Ellen Gottesdiener and Mary Gorman of EBG Consulting

Recently we worked with an agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in agile.”

That’s a myth. In agile development, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.

documentation-value-volume-relationshipProcess Versus Product Documentation

You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.

Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if they are building a regulated product and require evidence of product verification, as in our client’s case.

Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on.

For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos and, as a result, we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but it was also fast to produce. As a bonus, the delivery team found the format useful for on-boarding new team members.

On Your Mark…

Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as a larger set, created all at once).

When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a Lean start-up calls “validated learning”). For this team, it made sense to defer documentation.

A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.

Sliding Along the Documentation Levers

Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements; yet, when it was produced, it needed to be precise and formal.

There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.


The Low-Down on Documentation

Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.

Don’t forget to leave your comments below!

Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.


Categories: Companies

Day 1 at Agile 2014

Growing Agile - Wed, 07/30/2014 - 16:15

As with any conference, the amount of information and learning that happens is huge. Sometimes it feels like your head might actually explode! And yet, a mere week later we can’t recall half the things we learned. I find that really sad.

In an effort to keep our heads from exploding and to help us remember all the interesting bits, we have decided to do a video podcast everyday. Here is the first one – I hope you enjoy it!

Links to things we talk about:
Agile 2014

The Witches of Glum (part of the testing talk)

Clean Language

Lynne Cazaly

Categories: Companies

Agile 2014 Day One! Gators, Mermaids, and Alan Dayley Oh My!

BigVisible Solutions :: An Agile Company - Wed, 07/30/2014 - 16:07

Alan Dayley makes his way around Monday’s night networking event armed with a selfie stick and a microphone he captures attendees experiences and excitement around Agile 2014!

The post Agile 2014 Day One! Gators, Mermaids, and Alan Dayley Oh My! appeared first on BigVisible Solutions.

Categories: Companies

Mob Programming with Woody Zuill at Agile 2014

BigVisible Solutions :: An Agile Company - Wed, 07/30/2014 - 15:56

Mob Programming is a development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. The Whole Team works together to do almost all the work the team does – including coding, designing, testing, and working with the customer (partner, Product Owner, user, etc). We have expanded the “team” nature of all the work we do, not just the planning, retrospectives, and daily stand-up or other meetings, but all the work that the team does.

The post Mob Programming with Woody Zuill at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Martin Kearns Talks Through ‘The Lens’ at Agile 2014

BigVisible Solutions :: An Agile Company - Wed, 07/30/2014 - 15:19

Martin talks us through his Agile 2014 presentation.

How do you have coaching conversations with effects that are seen, heard and felt across the board? How do you have all encompassing, inclusive discussions which drive an enterprise towards a truly shared vision?

Agile is part of the answer, but to truly achieve amazing results from the ways we interact with each other, we believe that we also need to unlock the insight, wisdom and energy held captive within our teams and organizations. We have created a key, and we call it ‘The Lens’. It’s an engineered environment orientated around dialogue, transparency and co-creation, fostered through a combination of physical narrative and engineered experience for everyone from C-level executive to C# programmer and beyond.


The post Martin Kearns Talks Through ‘The Lens’ at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Llewlyn Falco – Teaching Kids Programming – at Agile 2014

BigVisible Solutions :: An Agile Company - Wed, 07/30/2014 - 04:32

For those interested in learning more about Teaching Kids Programming, visit their site  -  This is AWESOME!

The post Llewlyn Falco – Teaching Kids Programming – at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Get Real with Ron Jeffries and Chet Hendrickson at Agile 2014

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 23:00

Ron and Chet discuss their conference Q/A session experience, thoughts on the best sessions so far at Agile 2014, refactoring issues, Scaling Agile, and so much more!

Buckle up.

The post Get Real with Ron Jeffries and Chet Hendrickson at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Brian Bozzuto and Erin Beierwaltes talk Influence Strategy at Agile 2014

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 21:47

Brian and Erin talk with Dave Prior at Agile 2014 about how to leverage different types of influences to drive different outcomes or goals. They explore an array of influence and change strategies beyond the traditional top down models of influence by dictate.



The post Brian Bozzuto and Erin Beierwaltes talk Influence Strategy at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Peter Saddington discusses the Power of Mentoring at Agile 2014

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 21:24

Did you know that over half of Nobel Prize winners were apprenticed by other Nobel laureates? To grow companies and teams to performance you have to take servant leadership to it’s logical conclusion: Intentionally mentoring and growing others. This is a time-tested and practiced art.

Learn how you can take your teams to the next level of performance.

The post Peter Saddington discusses the Power of Mentoring at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Lyssa Adkins get’s intense at Agile 2014 – Need we say more?

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 20:02

Lyssa talks through the key skills for facilitating intense conversations.

Very few of us have the skills and experience to navigate intense conversations so when a hot moment arises, we often sidestep it, take it “offline”, or jump in to mediate it. We didn’t learn this stuff in school! But it’s time to learn it now.

The post Lyssa Adkins get’s intense at Agile 2014 – Need we say more? appeared first on BigVisible Solutions.

Categories: Companies

Diane Zajac Woodie Talks Gender Bias at Agile 2014

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 19:24

Diane speaks with Dave Prior at Agile 2014 and provides an overview of some common biases regarding gender. She looks at how some of the common practices used by agile teams may be perpetuating a culture of subtle inequality – and what you can do to begin to change this.

The post Diane Zajac Woodie Talks Gender Bias at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Why Agile Estimates Don’t Work – Part 2

TargetProcess - Edge of Chaos Blog - Tue, 07/29/2014 - 19:24

In Why Agile Estimates Don’t Work – Part 1 I’ve explained why estimates don’t work if someone sees them primarily as a commitment to timing. And, just as I expected, some aficionados rushed to educate me on the subject of estimates in agile, that they are not a commitment but, in short, a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Probably, some of those aficionados have accused me of the gravest sin ever, and namely, not reading Mike Cohn’s “Agile Estimating and Planning”. Relax, guys. I studied Cohn’s book long ago, and time after time I would flip its pages to refresh things in my memories, not to mention other books, articles and from-the-trenches stories. My most reliable source for making conclusions, however, is my work. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don’t work as commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than action itself?

What Is an Estimate? (take 2)

I’ve cited two options to answer this question in Part 1. Some people, who are, likely, not educated in agile theory, look at agile as a next best silver bullet to complete projects on time and they might wrongly view estimates as a promise of that. They genuinely believe that agile estimates will give them so much sought after reliable reference point about the time of completion. The second group of believers consciously accepts that estimating is a discussion of chances, a probability forecast. The burndown chart provides such forecast based on velocity. Let’s refresh the classical definition of velocity in our memory, quoting from here: “The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed“. Does it ring any bells now? If we never build the same feature twice, just as you can’t step twice into the same river, then why velocity-based forecast should be relied on? In general, this stands true for all the forecast techniques based on past performance, including forecast models. Yes, there are cases when a team’s work is monotonous, iteration in, iteration out, but from what I’ve been able to observe, it happens very rarely. Mostly, in any company and team, the tasks to be done and challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.

The Devil Is In…

.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself.  Nothing else explains this better than the good old Parkinson’s Law:


Yes, indeed. Having all the time in the world is loose. It’s either you have time, or you don’t have it. It’s either you have the guts and sixth sense to define what should be included to the minimal viable product, for instance, or not. Let’s not forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For the customers, and they don’t care about the development kitchen constraints, challenges and brilliant solutions. Same stands true for UX.

Now, how this reasoning fits into the subject of estimates, someone might ask? Here’s the astounding truth. Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There’s no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don’t do this. Rather than waste your time on playing with probabilities, get some real work done. Write code, do a UI sketch,  instill clarity to the work of your team. Some mathematical forecast model surely has it that a brick will fell on your head one day. But you’d hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You’d rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? This reminds me of the fact, that some business people who are skeptical about shamanism, astrology and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates. Come on, the estimate of completion based on burndown or a planning poker session, is as valid as an astrological forecast. There’s no big difference. It’s either you’re “fat” enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there’s always the bottomline point of “do or die”. That’s what a recent story with massive job cut by Microsoft proves. Ritual is a waste. If there’s time for rituals left, this is a sign of unhealthy fat. Burn it. If a workgroup discusses development, there’s no need to wrap it in the ritual of estimating, because when a discussion turns into a draining debate of “how probable” this timeframe is, the work suffers. Someone said, there’s a limited number of brains to do the job, and they should be used efficiently. One can suffice with a draft estimated timeframe, there’s no use trying to gauge on the likelihood of this happening, when there’s real work to be done.

Worship the Idol: How Do I Tell My Higher-Ups ..?

As life has it, however, most of us have to cope with the fallacy around estimates being employees in fat organizations, and, hard as you might, a mere human being can not move a mountain. There’s no way to persuade a higher-up non-developer manager, or a client, or a stakeholder in the vanity of estimates. That’s why people go on playing games, as they attend to those who expect a feature or a project to be done on time, as derived from estimate-related shamanic rituals. And, that’s where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily — there are more non-developers in the position of authority than developers. There’s always a point of litmus test, when someone with a developer background (a project manager, team leader, or someone in middle management) meets the non-developer stakeholder. Why I call it a booster for evolution? If every stakeholder were a developer, they would have probably ended up whining on each other’s shoulder about how difficult life is, and how impossible it is to commit to any timeframe. Having to deal with a non-developer stakeholder about a deadline is stimulating. If you’ve been thinking that something has changed from the hunter-gatherer times, I have bad news for you. The seeming “comfort” guises the basic instinct to act. You either act, or you rot. There’s no other option. No one cares for reactive rants. It’s your actions that define you. It’s your choice to agree to play the estimate game by the rules and accept this as a given, or to quit and find a job where they will not f…k your brain with estimates. If you choose to deal with ruthless stakeholders that are oh-so-not-understanding of how hard a life of a true software craftsman is,  move the conversation from the level of rant to the level of action. Use every opportunity to spread the awareness of the challenges that software development portends, and why this domain is un-deadline-ifiable by nature. Amazingly, there are so many people in this world who sincerely believe that an estimate is a credible measure for completion date. Write articles, speak on conferences, join the “no estimates” movement. Fix the gap between what you know, and what they know. If everyone has their say, this world will become a better place, with less projects and software screwed. And, even if you’d still have to deal with the waste of estimates, you’d feel better inside, because you’d be doing your all to change things, instead of ranting.

Enough of thought boosters (or busters?). In Part 3 of the series I will give an outline of some techniques, commonly regarded as techniques for estimates, that might work as a tool for workgroup discussions in some teams. Keep in mind the waste-value balance, though.

Related articles:

Why Agile Estimates Don’t Work – Part 1

Categories: Companies

Try AgileZen and Mobilize Social Entrepreneurs Worldwide

Rally Agile Blog - Tue, 07/29/2014 - 18:00
Limited Time Offer: AgileZen Impact Edition

Talk about the perfect way to combine your everyday work and your charitable side. Through August 31, become a new AgileZen customer and pay what you want for a three-month subscription to Impact Edition for up to 20 projects. Rally will donate 100 percent of new customer subscriptions during the promotion period to support emerging entrepreneurs who are tackling tough social problems worldwide. Plus, the Rally For Impact Foundation will match all those new subscriber contributions up to $5,000 to help the Unreasonable Institute further its global impact. Together, we can raise thousands of dollars in just a few months!

The Unreasonable Institute: Scaling to Meet Global Demand

The people at the Unreasonable Institute work tirelessly to get world-changing ventures and entrepreneurs the resources they need to scale their social and environmental impact. After running their global five-week accelerator program in Boulder, Colorado, for the past five years, they’re scaling their impact and launching two new institutes this summer -- one in Kampala, Uganda, and one in Aguascalientes, Mexico.

“Ever since we started the Unreasonable Institute, our big vision has been to open up dozens of institutes around the world, each serving entrepreneurs who are tackling the world's most pressing social and environmental problems. Unreasonable East Africa and Mexico are only the start of our global expansion. With the generous support from sponsors like Rally, we plan to open up many more institutes in the next year.” — Banks Benitez, vice president of global expansion, Unreasonable Institute

In 2011, Rally’s founder, Ryan Martens, spent his six-week, company-paid sabbatical at the Unreasonable Institute as a Mentor In Residence. Witnessing the power of the Unreasonable Institute's approach, Martens has continued as a Mentor every year since. He sees the AgileZen Impact Edition promotion as a great way to broaden the organization’s impact.

“I am thrilled to engage our AgileZen customers in supporting the global expansion of the Unreasonable Institute. Using a collaborative team approach, they teach social entrepreneurs to apply Lean startup approaches, including Agile techniques such as iterative and incremental cycles, to their business development efforts. Rally’s social mission is to mobilize citizen engineers — supporting people and organizations who are engineering social change through innovative products and programs. I’ve seen firsthand how the accelerator model gives social entrepreneurs an ‘unreasonable advantage’ to create true and lasting impact.” — Ryan Martens, Rally Software founder and CTO

Now is the perfect time to try AgileZen and make a difference with your contribution. Just sign up for Impact Edition as a new customer by August 31, decide how much you want to pay for a three-month subscription, and join Rally in helping people and organizations that are dedicated to improving lives in communities around the globe. To learn more about how AgileZen can help you and your team organize and track your work, take the product tour.

Geri Mitchell-Brown
Categories: Companies

The 4-Step Action Plan for Agile Health: Step 3: Understand how to use additional enablers of Agile Health

Agile Management Blog - VersionOne - Tue, 07/29/2014 - 17:02

Agile development requires a cross-functional, self-organized team to deliver potentially shippable software at the end of each sprint, with analysis, design, code developing and testing activities going on concurrently (not sequentially) within each sprint.      Combining Agile/Scrum development with some of the lean methods is also becoming popular (so-called “Scrumban” methods). These methods emphasize reducing Work In Process (WIP), reducing feature cycle time and increasing throughput (feature completion rate).

In my blog on From Agile Pathologies to Agile Health I explained that some “agile” teams suffer from the following common pathologies, i.e., major dysfunctions in practicing agile methods, while claiming that they are “doing agile”:

  1. Agile development “sprints” assigned to software development lifecycle phases
  2. Agile development “sprints” assigned to technology tiers
  3. Mini-Waterfall inside sprints
  4. Water-Scrum-Fall

While an agile team may not be exhibiting gross dysfunctions (pathologies) listed above, it may still behave in harmful or unhealthy ways that would prevent it from realizing the benefits of agile development, such as higher productivity, throughput and quality.    Absence of major pathologies or sickness doesn’t imply health; agile teams may still not be healthy due to one or more harmful behaviors.

In this 4-part blog series, I focus on 6 harmful behaviors exhibited by agile teams and how to move away from them, and transition to 6 healthy agile-lean practices in order to get more benefits (improved productivity, throughput and quality).  I also present 4 specific steps to transition to healthy agile-lean practices.   Table 1 summarizes these 4 steps, and labels 6 harmful behaviors (as 1B through 6B) and 6 healthy agile-lean practices (as 1P through 6P) for ease of cross-referencing. Table 1 also indicates what is covered in each of the 4 parts of the blog series: Part 1 and 2 (highlighted in light green color) were completed.    In this Part 3 (highlighted in pink color), Step 3 – understand how to use additional enablers of agile health – is described.  Parts 4 will be presented in the future.

Table 1: The 4-Step Action Plan for Agile Health


In Part 1 of this blog series, I used an example of a typical 4-week (20 workdays) sprint for the Struggling Agile Team.  Figure 1 illustrates the Sprint History Map of this 4-week sprint for the Struggling Agile Team after the sprint is over.   This Figure 1 is a revised version of Figure 1 of Part 1 as it shows the effects of two additional harmful behaviors, 5B and 6B, described below.


Figure 1:  Sprint History Map of the Struggling Agile Team
suffering from 6 harmful behaviors

5B. Frequent impediments and non-availability of qualified team members:   With struggling agile teams, there is often no disciplined way to minimize and manage impediments.  Team members (especially contractors supplied by an off-shore vendor) are reluctant to bring impediments to the attention of ScrumMaster in a proactive manner.  ScrumMaster may have difficulty in removing organizational impediments.  More importantly, the team may not have the required training and norms to prevent or minimize the impediments in the first place by taking timely proactive actions to resolve issues to prevent them from becoming impediments.  As a result, the number of impediments experienced by the Struggling Agile Team is rather large (as shown by 9 impediments — marked as IMP – on the Sprint History Map of Figure 1).  Furthermore, impediments may take substantial time to be removed, which holds up the work.

As shown in the Sprint History Map in Figure 1, a rather larger number of 32 cells are marked as NT (No Team Member Available) events because of frequent non-availability of qualified team members.   These members may be busy on other projects or teams due to multiplexing, or busy with other features due to multitasking, or are interrupted by customer support work or customer demos.  Members that may be available are not qualified or ill-prepared to do work outside their area of expertise due to the silo mindset.

Although it can be argued that NT events is an example of impediments (as no work can proceed due to non-availability of qualified team members), it is important to differentiate between NT events from general impediments to understand the gravity of problems caused by non-availability of qualified team members and then take appropriate actions to correct or mitigate that problem.

As shown in its Sprint History Map (Figure 1), the Struggling Agile Team planned 8 features, but could complete only 4 features (Features 1 through 4).  Four features (Feature 5 through 8) could not be completed.

6B. Manual testing is the norm: For struggling agile teams, the level of automation for unit testing, acceptance testing and regression testing is non-existent or at best low.    This creates an untenable situation as evermore regression test cases need to be run within each successive sprint to ensure that the functionality implemented in all previous sprints is still working, i.e., hasn’t regressed.  This growing effort for regression testing for each successive sprint with the same number of QA testers in the team performing manual regression testing is simply not feasible.  As a result, many teams do little or no regression testing in each sprint as shown in Figure 1; that effort is postponed until the so-called hardening sprint.   Neither the team nor its customers or users are clear about the quality of each sprint release as there was little or no regression testing done.

In Part 2 of this blog series, I used an example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team. Figure 2 illustrates the Sprint History Map of this 4-week sprint for the Healthy Agile Team after the sprint is over.      This Figure 2  is a revised version of Figure 1 of Part 2 as it shows the positive effects of two additional healthy practices, 5P and 6P, described below.


Figure 2: Sprint History Map of the Healthy Agile Team
following 6 healthy agile-lean Practices

5P. Effective impediment management and full availability of qualified team members: ScrumMasters should develop and practice these skills:

  • Encourage team members to bring to attention issues in a proactive way
  • Resolve issues before they have a chance to become impediments
  • Recognize real impediments that team members simply cannot resolve on their own
  • Develop technical and organizational skills to resolve impediments quickly if they still occur
  • When an impediment stops work on a feature (should be rare event), the feature team members may be assigned to help other feature teams, instead of pulling a new feature to work on (which increases WIP)
  • Apply the 5-Why’s technique (see: to find and address the root causes for recurring impediments

As a result of this practice, the number of impediments is minimized and impediments are removed quickly when they occur.  Compared to the Struggling Agile Team’s 9 impediments (see its Sprint History Map in Figure 1), the Healthy Agile Team encountered only 2 impediments (see its Sprint History Map in Figure 2).  NT (Non-availability of qualified team members) events can be completely eliminated for the Healthy team as shown in its Sprint History Map (Figure 2) because full-time, dedicated, cross-functional team members swarm on features; they do not squander their time on multiplexing or multitasking.  As shown in its Sprint History Map (Figure 2), the Healthy Agile Team planned 8 features, and completed 7 features (Features 1 through 7). Only one feature (Feature 8) could not be completed.

6P. Test Automation: Evermore regression testing is required in each successive sprint to ensure that the functionality built during past sprints is still intact and has not been broken, i.e., hasn’t regressed.  Unit tests are automated by following the practice of Test-driven development, and acceptance tests are also automated.  These two classes of automated tests are added to build the growing automated regression test suite.  It now becomes practical to run ever larger number of automated regression test cases on Day 18 and 19 of a 4-week sprint by using computers (typically virtual machines) as shown in Figure 2.   Although it is not possible to automate every test case, such as usability testing that involves subjective judgment, a vast majority of test cases are automated by the Healthy Agile Team.

I recommend to gradually growing test automation expertise within each cross-functional team.   If you have to depend on the availability of test automation experts controlled by some group or department, you will be back to harmful behavior 2B of Team members working with a silo mindset.   These test automation experts will always be in high demand by multiple teams, and often will become a bottleneck.

By no means, the list of 6 harmful behaviors and the corresponding 6 healthy agile-lean practices presented in this blog series is exhaustive.   More Practices for you to consider: Build automation, Continuous integration, DevOps, Refactoring, Technical debt reduction, Spikes, Waste reduction to improve lean flow, etc.

Now let us take a holistic view of all 6 harmful behaviors to move away from, and 6 healthy agile-lean practices to adopt.

Six harmful behaviors feed on each other to create more harm:  When multiplexing and multitasking is common, team members get distracted and lose productivity, which reduces throughput and increases NT events (work cannot proceed due to non-availability of qualified team members) as team members get pulled off to work on other multitasked work.   When team members work with a silo mindset and don’t have skills or inclination for cross-functional work, there are many NT events.  When team members have no focus on completing the work already started, WIP goes up, cycle time goes up, and throughput goes down.  Lack of test automation (manual testing is the norm) also reduces productivity and makes regression testing almost impossible in each sprint, which reduces quality.     As a result of all these 6 harmful behaviors, the Struggling Agile Team could get only 4 features (Features 1 through 4) accepted in the sprint representing a velocity of 8 story points.  The remaining 4 features (Features 5 through 8) could not be completed within the sprint.  A struggling agile team may continue to struggle into a downward spiral, until and unless it starts moving away from harmful behaviors and start following healthy practices.

Six healthy agile-lean practices feed on each other to create increasing benefits:  When multiplexing is avoided and multitasking is minimized, team members increase their productivity due to single-team loyalty and by not wasting time on context switching, which increases throughput and reduce NT events.     As teams develop and use cross-functional skills, NT events reduce dramatically as at least one team member is almost always available to do any work (each member is a Master of One and Jack of Two).  As team members follow lean mantra of Stop-Starting-Start-Finishing, and work in a highly focused way, WIP goes down, cycle time goes down, and throughput and quality go up.   As manual testing reduces, and Test automation increases, it increases productivity and makes regression testing possible in each sprint, which improves quality.      Instead of struggles caused by harmful behaviors, an agile team starts experiencing an upward spiral of improved health and consequent higher productivity, throughput, and quality.  As a result of all these 6 healthy-lean agile practices along with the practice of sprint pipeline, the Healthy Agile Team was able to get 7 features (Features 1 through 7) accepted in the sprint representing a velocity of 15 story points.  Only one feature of 1 story point (Feature 8) could not be completed within the sprint.   6 healthy agile-lean practices synergize to create more positive benefits. Success feeds on success

Are any of the 6 harmful behaviors causing serious challenges and issues in your organization?   Are any of the 6 healthy agile-lean practices giving your team tangible benefits or of interest to you for your adoption?

I would love to hear from you either here or by e-mail ( or on twitter (@smthatte).

Part 1: Understand harmful legacy Mindset and Non-Lean behaviors to move away from

Part 2: Understand healthy Agile Mindset and Lean Practices to adopt

Part 4: Develop and implement your customized plan for adopting healthy agile-lean practices

Categories: Companies

Agile Leadership Workshop – More Answers from the Expert

Danube - Tue, 07/29/2014 - 16:38

Ask the Expert icon1 300x71 Agile Leadership Workshop   More Answers from the Expert

Over the past two weeks I have been fortunate enough to be allowed to run 5 workshops on Agility in general. While these have been sales or marketing funded, I was allowed to run them without any interference and we were able to come up with some great interaction and engagement. One thing I did promise to each workshop was that any question I couldn’t answer during it I would type up and send out in a follow up email. Below is a collection of all the unanswered questions I was able to gather, I hope I didn’t lose any, but it is entirely possible with some of those hotel wonder-surfaces that are so resistant to post-its.

If I missed your question here just post it in a comment, I’ll see about getting it answered as soon as I am able. So without further delay:

– When to apply Agile vs Hybrid-Waterfall?

Hybrid-Waterfall *could* be Agile depending on what you are doing. I find a common misconception that we don’t do Up-Front planning in Agile often leads to this question. Always remember that the Product Owner decides what needs to happen to create our product and the order in which all the whats happen in. This means that a Product Owner could quite legitimately have the team do a lot more up front with estimation and analysis. When to do that however? That’s likely going to be a business decision that I always suggest is well informed. Work we spent analyzing and planning things that we never do is simply waste, and would have been better spent actually building something if that were possible.

– How do I get the team and stakeholders to get on board with moving forward with Agile practices?

This is one of the places that Agile Coaching becomes critical for most organizations. How you do this is pretty heavily dependent on your organization. I would say that something to keep in mind is that in our experience organizations that start with one important (but not the most important) project to apply Agile to, and give that project their all, (including finding people who want to try this and volunteer to do it) works much better then trying to apply Scrum to an entire organization. Pockets of strong agile practice and culture spread to the rest of the organization, where as a very broad but shallow adoption tends to lead people to fall back on old bad habits before giving it the time it needs to start working.

– Do you have tips for rolling up agile projects onto a dashboard portfolio?

First tip; do everything on purpose. Reports should inform a decision. Metrics must be fully understood if they are to be used. Often what seems to end up on such dashboards is a collection of just…stuff, that looks neat but maybe does nothing or very little. If you have software giving you reports automatically, as a by product of simply doing your work, those can be fine because they are little or no cost to product.

As to the specific things that I think are useful, I’d suggest having a look at Mike Cohn’s burndown:

It’s a little hard for many people to understand, which is why I usually express it in a burn up plotted every day on 2 lines, but if you can internalize what that report is saying and why you have a great place to start when it comes to Agile metrics.

I would also suggest finding some way to display (in a read only format) your Product Backlog(s). Always remember that a well groomed product backlog is a sort of a report in and of itself, telling you a lot of very useful things, especially if you use your velocity calculations to pencil in the currently estimated block of work that will make it into a fixed date release.

In truth this topic is way too complex for me to cover in this blog post, but if you like you can contact me and we can schedule a webex to cover exactly how we’ve solved some of these problems with our own software at Collabnet.

– How to transform iterative methodology into Agile.

I have good news, Iterative is Agile. It isn’t however Scrum, which I suspect may be the real question here. Usually when people describe to me their Iterative process what I get is a description of Scrum with less discipline and looser engineering standards, tooling, and practices. The best way to get better at your Iterative process is with the use of regular Retrospectives examining options for improving your process, and in particular I would suggest looking deeply into Scrum to see how close to that you can get.

– Most Common Mistakes made in unsuccessful agile and/or the key things for success.

I could list things all day here probably. There’s a myriad of things that lead to failure or success with agile, but f you get to the root of what I see most often it’s usually two things; A culture rooted in 20th century assembly line thinking and a lack of true Product Ownership.

– Do you produce (or need) Rapid Prototype using Scrum methodology?

To be honest I’m not 100% certain what is meant by Rapid Prototyping here, but if it’s what I am reading about online the concept of making something that can be shown to the end user is absolutely core to Scrum. I would say that if you are doing some form of Rapid Prototyping now for feedback purposes that you are likely already undertaking engineering practices that will work very well with Scrum. If anything you may find that Scrum simply makes your prototyping work even better.

The post Agile Leadership Workshop – More Answers from the Expert appeared first on

Categories: Companies

Quarterly Product Update

In this webinar, Jon Terry, COO of LeanKit, provides an overview of recently released product features and insight into what’s coming soon. During this discussion, you’ll learn:  About our plans to help improve your overall LeanKit user experience. How parent-child board connections help you visualize work, track progress, and identify risk. Details about our upcoming Reporting and Analytics overhaul and how it opens […]

The post Quarterly Product Update appeared first on Blog | LeanKit.

Categories: Companies

Steve Martin Rocks at Agile 2014 with an Experience Report

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 15:51

Steve Martin talks us through his session at Agile 2014 where he shares the challenges and outcomes from two separate transformation initiatives.

While both organizations are in rather risk-adverse industries (one financial and the other insurance), they invested heavily to introduce and scale Agile across an enterprise. Both wanted to transform their companies so that they could prevent severely dissatisfied customers from walking out the door, improve quality, and have better throughput, enabling them to respond to marketplace demands quicker.

One organization excelled – the other did not.

The post Steve Martin Rocks at Agile 2014 with an Experience Report appeared first on BigVisible Solutions.

Categories: Companies

Ken Rubin Talks Executive Level Agile with Dave Prior at Agile 2014

BigVisible Solutions :: An Agile Company - Tue, 07/29/2014 - 14:15

Ken Rubin talks through Agile transformation beyond the teams, and how to effect true, lasting change in an organization.


The post Ken Rubin Talks Executive Level Agile with Dave Prior at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies

Continuous Agile: A book review

Growing Agile - Tue, 07/29/2014 - 14:13

I don’t remember who suggested I read it or how it ended up on my kindle, but somehow I stumbled into reading “Unblock! A guide to continuous agile” by Andy Singleton. I was initially skeptical, do we really need a new way to do agile?

I started reading, and pretty soon I was hooked! I described the book to someone recently as a must read for coaches and Scrum Masters (and teams) who don’t understand version control with agile. I found the chapters on different version control systems and branching approaches vs feature switches excellent. The pros and cons of each were well explained, and I think even someone who isn’t a developer would be able to understand the different options. I’ve personally known for a while that feature branches whilst very popular can become a headache, but I’ve been out of development too long to understand what’s taken it’s place. I am now convinced feature switches are the way to go, thanks to this book.

The book doesn’t stop there, it takes a pretty radical approach to distribution, one that is not usually embraced in the agile community. In fact it’s pro globally distributed teams because of the benefits you get being able to hire the best people for your team regardless of where they are located. I don’t have a lot of experience with distributed teams working well, but the techniques mentioned in this book sound like they could work really well. If you are doing distributed agile, check out the suggestions here.

One of my favourite ideas is to stop interviewing people. Rather give them a job to do for a few weeks, even if it’s only a few hours a week because they have another job. At the end of the few weeks, discuss the work they contributed. Look at their code, and how they worked with the team. Then either offer them a permanent job or don’t. The reality is that no matter how good your interviewing technique is, it’s still hit and miss. But most of the people I know (myself included) can spot a bad hire in the first 3 weeks of them starting.

I must admit to being one of those touchy feeling hugging agile coaches that Andy mentions in the book, but I am glad to be able to say that I see a place for a different style. Andy’s book explains an approach that is pragmatic, based on technical excellence, and massively scalable. I highly recommend taking a look at his ideas.

Categories: Companies

Carol McEwan – Managing Director of Scrum Alliance – at Agile 2014

BigVisible Solutions :: An Agile Company - Mon, 07/28/2014 - 23:52

Carol McEwan – The Managing Director at Scrum Alliance, takes us through the growth strategy and evolution of Scrum Alliance over the past few years.

The post Carol McEwan – Managing Director of Scrum Alliance – at Agile 2014 appeared first on BigVisible Solutions.

Categories: Companies