“Everything is so chaotic.”
“Seems like we are constantly in a state of chaos.”
“Is agile always crazy and chaotic?”
Chaos is a word I hear a lot lately while working with software development teams that are either initially adopting agile software development or possibly undergoing a Lean/agile reshaping to improve their existing agile development approaches. I am often asked if the chaos will subside, and the good news is it will — to a certain extent. But to best understand when things will slow down (or even if they’ll slow down), it’s good to explore some of the causes that make things chaotic with agile software development.
And in my world, there’s no better way to assess than to make a list of Top 10 causes of chaos in agile software development:
1. New Teams Forming.
This one is obvious — as people come together to work with one another there’s a feeling-out period. Usually during this period, teams are learning how to collaborate and work through conflicts. In addition to the people learning to work with one another, there are plenty of established organizational structure and cultural barriers that slow the progress of agile teams forming.
2. Process Learning.
Another obvious one. Although most agile process frameworks (e.g. Scrum or Extreme Programming) are fairly easy and well documented, it takes time and practice to learn the mechanics. Couple this with #1 and, well, there can be some real challenges to getting things done.
3. HEAVY Learning Mode.
This may seem redundant, but it really cannot go under emphasized. In addition to learning about each other and learning the process frameworks, as engineers — we are constantly learning about technologies, learning about our products, learning about our customers, well — just getting smarter. Needless to say, this all adds up.
If you ever have watched the Deadliest Catch on The Discovery Channel, you get to see the struggles and pains of the first-time deckhands – called Greenhorns. They are often in way over their heads, running into challenges around every corner, and are just flat out exhausted. In addition to physically and mentally killing themselves, they are trying to prove themselves. Well, this is true with just about every new team member. Not only are they dealing with Items #1-3 above, the intensity of learning is magnified; until they have some wins and time under their belts, chaos exists.
5. When Quality is NOT Built-in.
It is my opinion that in software development, over the years we’ve invented this approach to quality that is “risky and invites failure.”  Yes, I stole that — in most software development shops, quality is something that is done by different people to ensure “separation of duties” and because of the mentality that ‘developers make bad testers.’ Couple that with the attitude that QA engineers can’t, or don’t necessarily need to know how to code, we have what we do today — a ton of end-of-stream testing, out-of-band automation efforts and, honestly, even the staunches of agile shops struggling with testing and ensuring quality. Without quality weaved into the Design>Build>Test cycle, we tend to see a lot more of these noisy things called Defects. Defects take a ton more time and energy than building it right in the first place.
6. Quality Automation Doesn’t Exist.
Without automation you’re going to find it almost impossible, or at least extremely constraining, to effectively and efficiently deliver software quality in a predictable manner. Similar to the “build quality in” challenges, teams often struggle because their estimation processes call out quality separately (which makes it a target for evil doers), and it often does not account for the work-around automation. Many organizations adopting agile software development don’t have an automation strategy for their legacy code. Therefore, they tend to have bouts of analysis paralysis around the problem space or they simply say, “our product or software is too hard to automate the testing” — so they won’t try. The other challenge around automation is that some see it solely as an end-of-line UI automation thing where a couple engineers work on it. Test automation is a holistic challenge and needs to be treated as such.
7. Lack of Cadence.
When teams are starting out, they don’t realize that the first thing to establish is their cadence — get their schedule in place and timebox everything. The cadence surrounds the process touch points that require formal communication and help us to build habits, thus making the process aspects of agile software development more muscle memory. If you feel like you are always in meetings or your iteration meetings are not occurring at the same Bat-Time and same Bat-Place, it might be time to reset; your cadence is lost.
8. Unpredictable Release Cycles.
This one is an enigma because there are teams I run into that say, “Our product is too large and complex to release in short cycles.” And then there are those that say, “We just release when we have to, it could be twice today or two weeks from now.” Looking at these two statements, they appear to be opposite in cause; however, it all comes down to #7 above and understanding what is the ideal batch size that reduces thrashing allows for tighter alignment among teams; reduces “Integration Hell;” and prevents the amoeba-style releases that never seem to end.
9. Deadline-Rich Environment.
Projects are the problem — or at least the traditional sense and meaning of a project drives the idea of fixed scope and fixed schedule. Let’s look at the PMI’s definition of ‘a project’:
A project is a temporary group activity designed to produce a unique product, service or result.
A project is temporary in that it has a defined beginning and end in time and, therefore, defined scope and resources.
At the end of the day, we drive our business off of the idea that of pushing for a date — we get emails from colleagues asking “when?”, we get emails from tools telling us “now!”, and we have other teams telling us “yesterday!” Ultimately, projects drive expectations that are generally dates; we can’t seem to get away from them until everyone realizes that we should design and define the scope to fit the schedule, not the schedule to fix the scope. This is because the schedule usually flexes in these situations, not the scope.
10. Estimation (and For That Matter, Capacity) is Not Understood.
We often see teams measuring productivity units of time versus being measured as units of value. This is the case even in mature agile shops. Everyone is so focused on trying to come up with a voodoo formula to determine capacity of a team or organization and another voodoo formula to normalize story points across teams in order to build a long-term plan based on the cooked-up numbers. The funny thing is that in many cases, the approach used for estimation doesn’t really change once an organization starts using agile. Everyone continues to plan predictively what we really don’t know. Agile software development is an adaptive approach to estimation and capacity. We work with what we know, we measure value, we assess complexity, and we often simply size efforts based on relative uncertainty. If people would just keep it simple, try to get all stories to the same level or near the same level of certainty, and do the same with the to-do’s (a.k.a. tasks and tests) — then in a couple iterations, teams could just count the stories and count the to-do’s accomplished within a timebox and use that for planning. Oh, if only it could be that simple … it is.
Okay, this was just my brainstorming or brain dump (literally) of 10 things that cause chaos in software development, in particular in the situations where an agile adoption or reshaping is underway. Just keep in mind, change is constant in business — now, more so than ever. Software development is complex; so are people. The great thing about tomorrow is that we don’t know what is going to happen. So, just practice and keep in mind: if today is bad — then there’s tomorrow.
Agile promotes that teams work in a sustainable pace to be able to keep delivering value to their customers. When agile teams are working under too much pressure, technical debt increases and the velocity and productivity of teams goes down. Agile retrospectives can help you to discover the causes of pressure and take actions to establish a sustainable and healthy pace with your teams.
A sustainable pace is a workload which a team can handle for a longer period, without compromising the quality of the product. It is based on a velocity that is doable for the team and doesn’t lead to stress or illness of the team members. Organizations can deploy agile processes that give teams flexibility to self-organize their work to manage their workload and flow.
When the workload of the team becomes too high, chances are high that team members will make more mistakes with increased technical debt as an result. Team pressure drives code quality down and increases maintenance. Due to the technical debt, the velocity of the team will decrease so they will actually be delivering less value to their customers while putting in more hours. Clearly a waste of valuable time, money, and energy of your people.
Finding the causes of team pressure
Some pressure is acceptable, but if you have the feeling that you are always working under pressure,the pressure is hampering your teams to deliver value to your customers, and the low quality of your products is costing you money, then that is something that should be addressed.
You can do that for instance with valuable agile retrospectives, by using exercises where team members state how they feel things are going. Facilitators can ask questions to discover what can be done to reduce the pressure. A retrospective can also be used to find the root causes of team members feeling constant pressure. You can do a five times why exercise to investigate the deeper causes of pressure.
How do you find out if teams are under pressure and what causes it? Here are some things coaches can focus upon in retrospectives, daily stand-ups, or in mentoring and coaching sessions:
- Do teams get enough freedom to do the work in the way they think it should be done?
- Are team members allowed to fail or make mistakes? Is it ok to learn from them?
- Is it just 1-2 people who are under pressure, or is it everybody on the team?
- How is the morale of your teams? What’s the atmosphere at work, and how do people react to each other?
- Do team members feel happy when they come to work, and when they go home?
Once you’ve identified that teams are under pressure and have learned what causes it, then they can take actions to address it in a next iteration.
Establishing sustainable pace
If a large workload is causing too much pressure and hampering teams, then they should take action.
Possible actions that they can take are:
- Commit to a lower number of user stories in the planning game. Build in slack.
- Investigate which improvements they can make to increase team velocity.
- Establish stable teams that are capable of delivering quality and maintaining high productivity.
- Prevent multitasking/task switching as much as possible.
- Monitor work in progress; use Lean and Kanban to steer on flow instead of working more hours.
- Plan time for team members to relax and blow off steam after having had a busy period.
- Focus upon happiness in your teams; make sure team members have fun while doing their work.
It’s important to follow up on the actions to verify that the pressure decreases so that teams can work in a sustainable pace. An effective way to do this is by doing short-cycled improvements: Observe how the team is doing in their daily work. Use opportunities to change the way of working to improve in small steps. And turn that into a new way of working for the team.
Collaborate with your stakeholders
It may be good for teams to involve their stakeholders to find workable solutions to reduce the pressure and find a sustainable pace that delivers value to them. Teams may have the opinion that stakeholders are causing pressure, which indeed can be the case. But often stakeholders are not aware that they are putting teams under too much pressure. Teams should discuss it with them, make them aware, and together look for solutions to decrease the pressure.
Building trust is important: The stakeholders should trust the teams by assuming that they will do the best they can, and the teams should secure this trust by continuously delivering valuable products. In the longer run, both the teams and the stakeholders will benefit from a sustainable pace by getting more value.
“If you want to deliver more, you should not work harder, but smarter” is a basic thing that didn’t change when agile was coined. Self-assessing how agile you are and doing smaller changes that stick using feedback and learning cycles from agile methods like Scrum are effective ways to implement lasting improvements. You need to invest time and energy, but when properly done, it certainly pays back. It helps you to stop death marches and to work in a sustainable pace.
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.
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.
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:
The Witches of Glum (part of the testing talk)
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.
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.
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.
For those interested in learning more about Teaching Kids Programming, visit their site - http://teachingkidsprogramming.org This is AWESOME!
The post Llewlyn Falco – Teaching Kids Programming – at Agile 2014 appeared first on BigVisible Solutions.
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!
The post Get Real with Ron Jeffries and Chet Hendrickson at Agile 2014 appeared first on BigVisible Solutions.
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.
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.
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.
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.
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.
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 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
The 4-Step Action Plan for Agile Health: Step 3: Understand how to use additional enablers of Agile Health
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”:
- Agile development “sprints” assigned to software development lifecycle phases
- Agile development “sprints” assigned to technology tiers
- Mini-Waterfall inside sprints
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: http://en.wikipedia.org/wiki/5_Whys) 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 (Satish.Thatte@VersionOne.com) 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
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: http://www.mountaingoatsoftware.com/agile/scrum/release-burndown/alternative
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 blogs.collab.net.
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 […]
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.
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.