The 4-Step Action Plan for Agile Health: Step 2. Understand how to adopt healthy Agile Mindset Practices and Lean Practices

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 (highlighted in light green color) was completed.    In this Part 2 (highlighted in pink color in Table 1), Step 1 – understand healthy “Agile Mindset” practices (1P and 2P) and 2 lean practices (3P and 4P) – is described.  Parts 3 and 4 will be presented in the future.

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

R_Part2_Table1

“Agile Mindset” practices to improve agile health:  I now explain and recommend 2 specific practices to embrace an “agile mindset.”   I typify an agile team B that consists of a business analyst, 3 full-time developers, 2 full-time QA testers, a Product Owner and a ScrumMaster.   All members of Team B are full-time, dedicated members unlike the Struggling Agile Team of Part 1 of this blog series which had part-time, multiplexed members.   As Team B follows all 6 healthy agile-lean practices (1P to 6P) listed in Table 1, it is our prototypical “Healthy Agile Team”.

I use a similar example of a typical 4-week (20 workdays) sprint for the Healthy Agile Team.   Figure 1 illustrates the Sprint History Map of this 4-week sprint after the sprint is over.   It uses the same format and legend as used in in the Sprint History Map of the Struggling Agile Team (see Figure 1 of Part 1). Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part2_Figure1

Figure 1: Sprint History Map of the Healthy Agile Team following the
Agile Mindset Practices

The 2 “Agile Mindset” practices (numbered 1P and 2P below) require replacing the legacy mindset with agile mindset, moving away from silo thinking, welcoming the change necessary for successful agile adoption and implementing the required change to get the benefits of higher productivity, throughput and quality.

1P. Full-time, dedicated agile team members without multiplexing and with minimal multitasking: Move away from the old mindset that treats people as resources whose utilization needs to be maximized via multiplexing and multitasking.   It is much more important that you maximize agile team throughput than worry about utilization of each team member as a resource.

Assign agile team members to work full time (100%) on a single agile team through all sprints of at least one release cycle.  You need at least a full release cycles (4 to 6 sprints) for team members to understand each other’s strengths and weaknesses, develop a (hopefully smooth) working relationship, and jell together as a team.  These well-jelled team members show higher productivity as they learn how to capitalize on each member’s strengths and compensate for weaknesses.  They learn to work with each other as human beings, and not replaceable resources.  This often requires a significant buy-in from management, if it is steeply rooted in traditional project management practices.

Cultivate the habit of doing focused work – one task at a time – starting with 30 minutes of uninterrupted work on a single task, and gradually extending it up to two hours.  Then you will need a well-deserved 5-minute break due to intellectual fatigue.  See The Energy Project: http://theenergyproject.com/  to understand how to conserve your energy to work in a highly focused way on single task at a time. Each team member learns to focus on a single task at a time (up to 2 hours in a stretch) until the task is over, before switching to other tasks.

Avoid multiplexing and minimize multitasking.  It increases productivity by avoiding wasteful context switching, and making each team member committed to and accountable for the success of a single team.  There are no divided loyalties of a person among different teams and projects.  That simply doesn’t work well.

2P. Cross-Functional Team Members: An agile team is composed of cross-functional team members: Train, cultivate and invest in each member to become a “Master of One and Jack of Two”.   Each member has primary expertise or mastery in at least one area, and working level skills in two other areas.  From time to time, each person is needed to work in areas outside his/her own mastery.  For example, a developer tests features developed by other developers, or a tester develops scripts for automated tests, etc.   See: http://bit.ly/1lkaXHc.

Investing in team members to become “Master of One and Jack of Two” may require a significant buy-in from functional or departmental managers.   Team members don’t just do their own tasks that match with their primary expertise or interest.  They swarm as a team to deliver working features within each sprint. Each feature is worked on by a logical feature team swarming to complete the feature in the shortest cycle time.  See: http://bit.ly/1rhtV6g.  Although the Sprint History Map for the Healthy Agile Team (Figure 1) shows swarming feature teams only for Feature 1 and 2 for brevity, they exist for all 8 features in the backlog.  These feature teams are “logical” teams in the sense that they may share one or more individual team members.

How to adopt two lean practices:  These 2 lean practices (labeled 3P and 4P in the list of 6 healthy agile-lean practices of Table 1) are described below.

3P. Stop-Starting-Start-Finishing and work under WIP limit: Form swarming features teams within an agile team to focus attention on getting each feature accepted by the Product Owner as soon as possible.  Without completing a feature or a task already in progress, resist the temptation to start working on a new feature or a new task.  Stop starting new things (features or tasks) before completing the things you have already started.  This is a good mantra for life too.   This practice will effectively allow a lower WIP limit in an informal way.

As explained by David Anderson in his book “Kanban: Successful Evolutionary Change to your Technology Business,” 2010, page 114, the WIP limit needs to be set up as 2 to 3 people per feature plus 2 to 3 to smoothen the impact of a blockage.   For an Agile team of 7 full-time, dedicated team members, the WIP limit can be set up as 3 + 2 = 5.   You will need to experiment with this number and adjust it empirically up or down based on the experimental results.  Progressively lowering WIP limits will bring out bottlenecks that need to be resolved.  Agile Lifecycle Management tools, such as VersionOne, help you visualize the Kanban workflow under WIP limits, and provide warnings if WIP limits are exceeded.  Learn how to work with smaller WIP limits.

As shown in the Sprint History Map (Figure 1), the WIPs on Day 2 through 17 (total 16 days) for 7 completed features (Feature 1 through 7) in the sprint are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 2, 2, 1, 1, with the average WIP = (46/16) = 2.875.    The WIPs on Day 2 through 17 (total 16 days) for all 8 features are 2, 2, 2, 3, 4, 5, 4, 4, 3, 4, 4, 3, 3, 3, 2, 2, with the average WIP = (50/16) = 3.13, which is only slightly more than the WIP of 46/16 = 3.13 for 7 completed features.  The Healthy Agile Team has its focus on completing the work in progress before starting the new work by following the Stop-Starting-Start-Finishing mantra which reduces WIP.   The Healthy Agile Team has a smaller WIP compared to that of the Struggling Agile Team illustrated in its Sprint History Map (see Figure 1 in Part 1, and the WIP data for the harmful behavior 3B in Part 1).

4P. Focus on minimization of cycle time: Improve team’s throughput (features completion rate) with cross-functional team members, eliminate NT events by avoiding multiplexing and multitasking, and use of proper test automation tools (see Part 3 of this blog series).

Reducing WIP reduces the cycle time.    As shown in the Sprint History Map (Figure 1), the cycle times for the 7 completed features (Features 1 through 7) are 6, 8, 5, 7, 7, 8, 5 days, with an average cycle time of (46/7) = 6.57 days.   I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Healthy Agile team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In the example of Healthy Agile Team, Average WIP = 46/16 (see Practice 4P above), and Average Cycle Time = 46/7 (as explained just above).

Therefore, Average Throughput = [(46/16) / (46/7)] = 7/16 features per day.

You may use the Sprint History Map (Figure 1) to visually verify that the Healthy Agile team has  delivered 7 accepted features (Features 1 through 7) in 16 actual work days of the sprint, confirming the average throughput of 7/16 features per day.  Sprint History Maps provide visual data for WIPs and Cycle Times, and visual verification of Little’s law.

The higher throughput of 7/16 features per day for the Healthy Agile Team (compared to the Struggling Agile Team’s throughput of 4/18 features per day) can be attributed to the facts that the team has moved away from harmful behaviors:  it has no NT events and substantially reduced number of  impediments (IMP events); it avoided multiplexing and minimized multitasking, gotten away from the silo mindset,  is practicing Stop-Starting-Start-Finishing lean mantra, has reduced long cycle times (average cycle time of only 6.57 days in a 16-workday sprint), and is practicing automated testing (as will be explained in Part 3 of this blog series).

Little’s Law is a powerful and versatile tool.  A change in any one of its parameters (WIP, Cycle Time and Throughput) is most likely to effect a change in one or both of the other two parameters.  You can reduce cycle time by reducing WIP while holding throughput constant.  Or you may increase throughput by decreasing cycle time as we have just seen.  There is a third option: a team may increase the average WIP (more work in parallel) and thereby increase the throughput, provided that the team can hold the average cycle time by increasing its intrinsic productivity by upgrading its skills via training and apprenticeship, getting more experienced members on the team, using various automation tools, increasing its design and code reuse, etc.   If any one of these 3 parameters needs to be corrected or improved, Little’s Law tells us exactly what to do to achieve the desired results.  Most of the time the goal is to increase throughput (without sacrificing quality) by reducing cycle time or by increasing team’s intrinsic productivity or both.   Bennet Vallet of Siemens Health Care presents a great case study of Kanban success providing the details of how to harness Little’s law to reduce the average cycle time, increase the average throughput and improve the release predictability.

Lean methods provide us additional options to reduce the cycle time, and thereby, increase the throughput.  Splitting large features into smaller features (they still must deliver value to customers) reduces the average cycle time.   How small should these features be?   Larman and Vodde suggest that for an N-week long sprint, each feature should take no more than N/4 staff-week of total effort (Reference: “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120).  For the 4-week example sprint used in this blog series, it would be ideal if each feature takes no more than 4/4 = 1 staff-week or 40 staff-hours (or less) of total effort.  For a 2-week sprint, each feature should take no more than ½ staff-week or 20 staff-hours of total effort.

Furthermore, leveling the workload, i.e., having all features of roughly the same size also reduces the average cycle time.  Uneven sized sprint workload (small features intermixed with medium and large features in a sprint backlog) increases the average cycle time.

As shown in the Sprint History Map (Figure 1), the Healthy Agile Team has swarming feature teams; each feature team is working on multiple tasks of a feature concurrently.  For example, in the Sprint History Map (Figure 1), Software Design task (D) and Acceptance Test Development task (TD) were going on concurrently on Day 2, Code development task (C) and Acceptance Test Case execution task (TE) were going on concurrently on Day 4.  This swarming action also reduces the cycle time due to intense collaboration among the feature team members, their focus on completing the feature and getting it accepted as fast as possible.

Sprint pipeline: Learn and apply the Sprint pipeline practice where feature analysis and UI design work is done one timebox ahead of software design, coding, testing, defect fixing, acceptance testing.   This effectively allows two successive timeboxes for each sprint, but without adversely impacting throughput (it still produces working software at the end of each sprint).   With sprint pipeline, feature specification and UI design is in much better shape when a sprint starts, compared to trying to squeeze all work for a feature in a single time box where analysis or UI design may become bottlenecks.   In the Sprint History Map (Figure 1), there are no “A: Analysis” tasks at all, because the Healthy Agile Team is following the sprint pipeline well. 

Is your team facing the challenge of moving away from harmful “legacy mindset” and “non-lean” behaviors, and is interested in transitioning to the healthy “agile mindset” and lean practices?  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

Stay tuned for these future parts of the blog series:

Part 3: Understand how to use additional enablers of Agile Health

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

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Agile Training, Iterative Development, Kanban, Lean, Lean Software Development, Scrum Development, Scrum Methodology | Leave a comment

An Open Letter to Executives Leading Agile Transformations

Dear Executive,

Let me congratulate you on your decision to introduce agile methods within your organization. It is a wise decision that holds incredible potential for your employees, your company, and especially your customers. If you are just beginning your improvement, or are yet to begin, the journey upon which you are about to embark is one that will be well worth the effort. And it will take effort—long, arduous, and at times frustrating effort.

Although Machiavellians do exist, my experience is that they are exceedingly rare.  In general, people are good, honest, and hard-working and really want to do the right thing. We hold a desire to do our jobs well, be recognized for it, and make a difference in the world by being part of something larger than ourselves; to have a purpose at work, if you will. To this end, we will do what is necessary to get our work done in the manner that our environment best supports. Put more simply, we will take the path of least resistance and complexity. Your move toward agility may be more challenging than necessary if you don’t keep this in mind while traversing your path toward improvement.

Rather than simply introducing and mandating agile methods such as ScrumeXtreme Programming (XP), and/or Kanban, create an organizational environment where agility is the path of least resistance for your employees and colleagues to get their work done. Here is a ten-step plan of action to help you create that environment within your organization.

  1. Stop referring to the change as organizational and/or agile transformation. We’ve all heard and understand the cliché that “change is the only constant.” Using phrases like agile transformation can shoot fear of the unknown into the psyche of everyone as it screams massive change. A less scary word is improvement. We all like to improve. Start talking about improving delivery, increasing customer engagement, and enhancing responsiveness to new challenges.
  2. Restructure your organization to reduce emphasis on functional specialization.One of the factors strongly contributing to the slow responsiveness of waterfall is the typical hand-off of work as it passes from the hands of one functional group to another—Business Analysts for requirements to Architects for design, to Developers for build, etc. Create teams that are cross-functional and require little to no hand-off of work. If so desired, create Centers of Excellence (CoE) organized around professional career ladders but remove reporting ties to any functional manager in the CoE.
  3. Start demonstrating the behavior you desire in your organization. One of the most powerful ways to build momentum is to first change yourself and your behavior. You really can’t force change within others, but you can inspire it. It’s amazing the change you’ll see in others when you first seek to change yourself. Actively seek ways you can serve the teams within your organization. With genuine curiuosity, caring, and empathy ask them what gives them headaches in their jobs. Be the aspirin for these headaches and remove the obstacles that are getting in their way. You might also consider working cross-functionally as a leadership team. Break down functional silos by creating teams that consist of representatives from many departments such as sales, marketing, IT, support, etc. The gears in any machine only work if cogs make contact and work collectively.
  4. For technology projects, refuse to move forward on any project without business representation and team involvement. Be uncompromising about beginning any project that does not have business representation. I was recently asked what I thought was the one thing that, if it did not exist, you could not consider yourself to be agile. This is that one thing—business involvement. If it’s not important enough to warrant business involvement, it’s not important enough to work on. Thank you, Samar Elatta, for this reminder because it’s so obvious it can easily be overlooked.
  5. Completely drop discussions of “resource allocation” and speak only of “team availability”. Agile is a team sport. The focus needs to shift from individuals to teams. Instead of identifying individuals within a functional specialty and percentage of availability to do work seek out only complete teams with availability. Also, don’t begin work with incomplete teams. Have all of the requisite skill sets available so you can avoid slowing them down with the burden that’s created to bring a new team member up to speed on the project.
  6. Increase your delivery cadence. The ideal situation is to be able to deliver at any time (or all the time, as in continuous). Take incremental steps toward this goal by reducing the delivery window by at least half. If you’re on a semi-annual (6-month) delivery cycle reduce it to quarterly. If it’s annual, reduce it to semi-annual; quarterly, release every six weeks. This will automatically require teams to focus on smaller increments of work instead of looking at very long horizon delivery windows that only serve to increase estimating complexity and uncertainty about scope of delivery.
  7. Give high praise for “complete” features only. The only features that provide customer value are those that are complete. Almost done features may have future value potential but they have zero value right now. Consider work either done or not done. There is no credit for work that is not 100% complete. Define expectations very clearly for what is meant by “complete”.
  8. Recognize entire teams. The best way to support teamwork is to value and recognize teamwork, especially in a public setting. Praise entire teams and avoid the temptation to call out individuals on the team that did an excellent job. While it’s true that some of them may well have went above and beyond, it’s dangerous to the cohesiveness of the team if you praise an individual. If you must mention names, mention the names of all individual members of the team. Only the team (those on the frontline of value delivery) has the credibility to recognize individual team members for their efforts.
  9. Don’t mandate a methodology at the team level. Rather than requiring teams to do Scrum, or any other methodology framework, put the ingredients in place for agility such as those described in points 1-8 above, provide and demonstrate your personal support and commitment to the removal of organizational obstacles and dysfunction, and stand out of the way. These people are professionals, they are smart, and are very capable. If not, why are they working in your organization? They will do what’s required to get the results expected of them, sometimes regardless of whether those results are even realistic. This is autonomy and is one of the incubators of the only form of motivation that is effective, intrinsic.
  10. Invest in your workforce and your teams and they will invest in you. I do not tolerate tales of woe about organizations experiencing a lack of worker loyalty when those same organizations refuse to invest in their workforce. When times get tough and the C-suite is getting pressure to show near-term stock price growth, drastic measures are taken to reduce costs. Unfortunately, these short-term measures such as workforce reductions, slashing benefits, and cutting investment in training usually have a negative long-term effect. Make decisions that will positively impact the long-term value of both your stock price and your organization (boths its viability and people). If you’ve created an unsustainable cost structure that requires drastic measures, then you obviously need to take some drastic measures. If you and your management team created it, admit it because your people probably already know it. They have great “BS” meters and will see right through any attempt you or your leadership team make at masking it. Demonstrating humanity through vulnerability and admitting personal fault may feel terrible but it will increase your credibility in the eyes of your constituents by orders of magnitude. If you create an environment that inspires workers to give their all, run a company that gives to the community, and demonstrates that it values its workforce by investing in them, you and your organization will have a much greater chance of competing in the marketplace for a long time to come.

I opened this letter by expressing my belief that people are generally good, honest, and want to do the right thing. I close this letter by restating that this belief I hold has only been reinforced through my personal interaction with a diverse group of colleagues throughout many organizations spanning a long career. I would like to affirm that this belief also extends to you, the organizational leader. I believe that you genuinely want to do the right thing, to contribute to something larger than yourself, and to support those around you to improve the quality of life for each of us.

With high confidence in your ability, personal desire, and integrity I urge you to create an environment within your organization that inspires those around you and that enables agility. The future of your organization is depending on it.

Posted in Agile Adoption, Agile Coaching, Agile Management, Enterprise Agile, Scaling Agile | Leave a comment

The 4-Step Action Plan for Agile Health: Step 1. Understand “Legacy Mindset” and “Non-Lean” behaviors to move away from

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: analysis, design, code development, testing and defect fixing, delivery and deployment activities are carried out in sequential “sprints.”
  2. Agile development “sprints” assigned to technology tiers: user interface tier, business logic tier and data management tier work are carried out in sequential “sprints.”
  3. Mini-Waterfall inside sprints: for example, in a 4-week sprint, week 1 is used for analysis and design, week 2 for code development, week 3 for testing, and week 4 for defect fixing, i.e., these activities (design, code development, testing, defect fixing) are sequential, creating a mini water fall; they are not concurrent as required by true agile development.
  4. Water-Scrum-Fall: Although design, code development, testing and defect fixing go on concurrently in each “sprint,” there is a fairly long Requirements Analysis phase carried out upfront prior to the first sprint by a group of business analysts producing a comprehensive Requirements Specification document; and at the end of the last sprint, IT Operations staff spends a fair amount of time in deploying the system in a production environment, often finding problems that are expensive to fix.

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: In this Part 1 (highlighted in pink color), Step 1 – understand “Legacy Mindset” behaviors (1B and 2B) and 2 “non-lean” behaviors (3B and 4B) – is described. Parts 2 to 4 will be presented in the future.

R_Part1_Table1

In this blog series, I typify an agile team A consisting of a business analyst, 2 full-time developers and 2 half-time developers, 1 full time QA tester and 2 half-time QA testers, a Product Owner and a ScrumMaster.  Business analyst works with product owner to write and clarify feature specifications as part of Analysis tasks.  As you will see shortly, Team A exhibits all 6 harmful behaviors (1B to 6B) listed in Table 1; it is our prototypical “Struggling Agile Team.”

In this blog series, I use an example of a typical 4-week (20 workdays) sprint.  Figure 1 illustrates a Sprint History Map of this 4-week sprint for the Struggling Agile Team after the sprint is over; it is not a sprint plan projecting what will happen in future on each of those 20 days; this kind of plan would be a total anti-pattern for agile development.  In Part 4 I will explain how to get information to construct a Sprint History Map as a visual metric for gaining critical insights that you can act on.  The 20 workdays of the sprint are shown as columns numbered 1 through 20 Figure 1.

The Struggling Agile Team completed sprint planning on Day 1 where the Product Owner rank ordered the sprint backlog of features.  In our example, the sprint backlog has 8 rank-ordered features (also called “stories”) shown under the backlog column in Figure 1.  During sprint planning, the Struggling Agile Team also estimated the relative effort of features in story points.  For example, Feature 1 is of 1 story point (indicated by “1, 1”), Feature 2 is of 3 story points (indicated by “2, 3”), and Feature 8 is of 1 story point (indicated by “8, 1”).  In this example the Struggling Agile Team planned 8 rank-ordered features representing a total effort of 16 story points.  Each feature was broken down into its implementation tasks either during sprint planning or actual sprint execution.  These tasks are indicated in the legend at the bottom of Figure 1.

R_Part1_Figure1

Figure 1:  Sprint History Map of the Struggling Agile Team suffering from
“Legacy Mindset” and “Non-Lean” behaviors

Two harmful “Legacy mindset” behaviors to avoid:   I have called these 2 behaviors as “legacy mindset” behaviors because they arise primarily from legacy habits and practices of old waterfall days, silo mindset, and resistance to cultural change needed for agile adoption to succeed.  These behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting full benefits of agile development.

1B. Multiplexing and Multitasking is common:  Members are tasked by management to work on multiple concurrent teams of the same project or even different projects.  The behavior is rooted in the traditional project management mindset of treating people as resources and attempting to maximize their utilization by assigning them to multiple concurrent projects or teams.  This behavior is further driven by the fact that most people are narrow specialists; they are assigned to do work in their specialization on multiple teams or projects, as there is usually a shortage of other people to do that kind of work.

It has been reported that a team member working on two concurrent teams or projects loses 20% productivity due to frequent context-switching.  A member working on 3 or 4 concurrent teams or projects may lose 40% or 60% of productivity respectively, due to frequent context switching (Reference: Quality Software Management: Systems Thinking, Gerald Weinberg, 1991).

Multitasking behavior is also common.  Team members work on several tasks of different features of a sprint that match their skills often concurrently (frequently switching from one task to other), or team members may be pulled away for production support work or customer demos.   Their work gets frequently interrupted by meetings, phone calls, people stopping by for discussions, as well as self-imposed urge to check and respond to emails and instant messages incessantly, and in general, due to lack of self-discipline to focus on one task at a time.   Like multiplexing, multitasking also diminishes productivity.  Unlike CPUs, humans are not well suited for multiplexed or multitasked work.  Unfortunately, the trend is to do extreme multitasking: doing work, web surfing, tweeting, “Liking” on Facebook, talking over phone, replying to email and instant messages, and eating…all concurrently.   Single-minded focus means “while eating, only eat with single-minded focus on enjoying food.”

Thus in reality, the Struggling team has at best 2.8 (not 3) equivalent developers with its 2 full-time and 2 part-time developers, and 1.8 (not 2) equivalent testers with its 1 full-time and 2 part-time testers.  The team members’ effectiveness and productivity is further reduced proportional to the degree of multitasking they may indulge in.

2B. Team members with silo mindset develop features in a “micro waterfall” manner:  Each member works on only specialized tasks suited to his/her expertise or interests.   Departmental silo mindset is common.  A developer is reluctant to test code written by other developers, a tester is not skilled to write automated acceptance tests, an architect is reluctant to get down into trenches and write code, a technical writer rarely does usability testing, etc.

A team is also likely to develop each feature in a sequential “micro waterfall” by performing the implementation tasks (analysis, design, code development and unit testing, acceptance test case development, acceptance test case execution, defect fixing, etc.) within the sprint timebox in a linear order.  Although the Sprint History Map in Figure 1 shows only three micro waterfalls (for Features 1 through 3) for brevity, all 8 features are developed in a micro waterfall manner.    In a micro waterfall there are very few concurrent activities.  As a result, in the first half of a sprint, most developers of the Struggling Agile Team are too busy and testers believe they don’t have much work to do until developers have completed all their work.  This picture reverses in the second half of a sprint; testers get too busy and developer don’t have much to do.

Two harmful non-lean behaviors to avoid: I have called these 2 behaviors as “non-lean” behaviors because they arise from not understanding the relevance and importance of key lean principles and practices.  Just like “Legacy mindset” behaviors explained above, these non-lean behaviors give rise to many difficulties in successful agile adoption and prevent the teams from getting benefits of agile development.

3B. Team members start new work without any focus on completing the work already started: Most team members eagerly start working on new features and tasks of their personal interest with almost total disregard to features and tasks that were already started and are still in progress (Work in Process).  There is no focus on completing the features and tasks they have already started.   After all, starting new features is more exciting work compared to fixing defects in features that were already started.  The less exciting work of completing the features already started and getting them accepted by the product owner gets short shrift.     Similarly, due to multitasking habits, starting a new exciting task within a feature is much more tempting, leaving many “boring” tasks unfinished until the very end of the sprint timebox.

As shown in the Sprint History Map of the Struggling Agile Team (see Figure 1), the Work in Process (WIPs) on Day 2 through 19 (total 18 days) for 4 completed features (Feature 1 through 4) in the sprint are 4, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3, 2, with the average WIP = (68/18) = 3.77.  However, the WIPs on Day 2 through 19 (total 18 days) for all 8 features are 3, 4, 4, 6, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8, 8, 7, 6, with the average WIP shooting up to (123/18) = 6.83, i.e., almost 7 features (out of 8 in the backlog) being worked on by the team in parallel!   The Struggling Agile Team does not have the required focus on completing the work in process before starting new work.  As a result, at the end of the sprint, only 4 out of 8 features were completed by the team and accepted by the product owner.   Sadly this Struggling Agile Team claimed that the remaining 4 features (Features 5 through 8) are “almost done” while in reality they took considerably more time in the next sprint to complete.  With proper coaching and experience the team learns that a feature is either 100% Done or Not Done, and there is no such thing as “Almost Done” or “98% Done.”  It is very binary.

4B. Work within a sprint proceeds oblivious to feature cycle time:  Feature cycle time (cycle time in short) is the total end-to-end time starting from when team members pull the feature from the sprint backlog to work on until the feature is accepted by the product owner after it passes the acceptance tests.   In Figure 1, cycle time for Feature 3 is 18 days, i.e., day 2 through 19 of the 4-week sprint.  Cycle times for the 4 completed features (Features 1 through 4) are 16, 17, 18, 17 days, with an average cycle time of (68/4) = 17 days.  This Struggling Agile Team is unaware of the importance of reducing the average cycle time, and could not complete 4 features within the sprint timebox due to their long cycle times.

I will now use the well-known Little’s Law to calculate the average throughput (rate of feature completion and acceptance by product owner) of the Struggling Agile Team.

Average Cycle Time = Average WIP / Average Throughput, or alternatively

Average Throughput = Average WIP / Average Cycle time

In this example, Average WIP = 68/18 (see Behavior3B above), and Average Cycle Time = 68/4 (as explained just above).

Therefore, Average Throughput = [(68/18) / (68/4)] = 4/18 features per day.

You can use the Sprint History Map (Figure 1 ) to visually verify that the team has delivered 4 accepted features (Features 1 through 4) in 18 actual work days of the sprint, confirming the average throughput of 4/18 features per day.

This low throughput is caused by the fact that the team is new to agile (low productivity due to learning curve), and also due to its own harmful behaviors:  it lost productivity due to frequently non-available members (NT events) and due to impediments (IMP events) marked in Figure 1.  This will be explained in Part 3 of the blog series.  Also due to multiplexing and multitasking, silo mindset, no emphasis on finishing the work that was already started, long cycle times (average cycle time of 17 days in an 18 workday sprint), and manual testing (explained in Part 3 of this blog series).  The Struggling Agile Team could not do any regression testing within the sprint due to its practice of mostly manual testing.  This will be explained in detail in Part 3 of the blog series.

When Features 5 through 8 are completed in the next sprint (if that were to happen), it would be possible to consider the WIP on every day of two consecutive sprints for these 8 features and any new features started and completed in the next sprint, and also consider the cycle times for these 8 and new features over two sprints to calculate the average throughput per day over two sprints by following the procedure above.

The Struggling Agile Team failed to recognize the need for limiting the WIP and lowering the cycle time.  Large average WIP means large average cycle time, which increases the risk of many features not being completed and accepted within the sprint timebox.    The Struggling Agile Team is simply oblivious to the implications of Little’s Law.

The Struggling Agile Team attempted to do all work for each feature (shown in Figure 1 as A: analysis, D: Design, C: Coding, TD and TE: Acceptance Test Develop and Execution of QA tester, DF: Defect fixing, AT: Acceptance testing by product owner) in the same single sprint timebox as this workflow is simple to understand and to follow.   However, this behavior created many adverse effects as the answers to some analysis questions raised by team members could not be available immediately; a product owner had to talk to customers or senior management to seek clarifications, and those answers took too much time to complete all development within a tight sprint timebox.  As user interface design work could be tested only through working code, the feedback cycle was too long to correct the UI issues in the same single sprint timebox.  Analysis and UI design work, and associated clarifications and corrections for certain features took too much time to complete the feature within a single sprint.  What the Struggling Agile Team failed to recognize was that Analysis and UI design work had become bottleneck hampering the overall flow and increasing the cycle time; but the team didn’t know what action to take to remove the bottlenecks.

Is your team experiencing the harmful legacy mindset and non-lean behaviors, and looking for solutions?   I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

Stay tuned for these future parts of the blog series:

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

Part 3: Understand how to use additional enablers of Agile Health

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

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Metrics, Agile Project Management, Iterative Development, Kanban, Lean, Lean Software Development, Scrum Methodology, Scrum Software | Leave a comment

Make Agile 2014 PEACHy

This year, I’m excited to be returning the Agile Conference. Having organized and participated in the conference from 2001-2005, my attendance became sporadic as the beginning of the youth football season (my other coaching gig) won out over the annual agile pilgrimage. Preparing for the show brings back many memories, but also some lessons learned that I wanted to share for anyone new to the conference or looking to get a little more out it. In true agile form, I’ve made a pithy acronym. Follow these suggestions and after the conference, you’ll be saying, “That’s a PEACH, hon!”

Prepare
The Agile Alliance Agile2014 Pre-Conference Planner is a great resource for planning your conference activities. Obviously, you’ll get the most out the conference if you review the sessions and target the sessions you don’t want to miss (MoSCoW anyone?). For your most important sessions, check out the room size. As part of a commitment to an open learning environment, the conference does not reserve seats, nor limit your ability to participate. The most popular sessions will fill their rooms, leaving some standing or not able to attend. In your conference guide, you can get a sense of the room size. If your must-see session is in a smaller room, GET THERE EARLY!!

There is great content to choose from. Pick your targets, but include one or two sessions that are out of your box and may give you empathy for someone else’s kind of work. If you need ideas, check out these sessions being given by the nearly 20 speakers from VersionOne and our partners:

VersionOne: Matt Badgely, John Krewson, Steve Ropa
agile42: Richard Dolman, Martin Kearns
Cognizant: Raje Kailasam
DavidBase: Jeffery Davidson
DevJam: Matt Barcomb, David Hussman
Improving: Ken Howard
LeadingAgile: Mike Cottmeyer, Derek Huether
Lithespeed: David Bulkin
SolutionsIQ: Daniel Gullo, Tim Myer, Dhaval Panchal, Charlie Rudd, John Rudd

Engage
The conference can be overwhelming with tons of people, tons of sessions, tons of exhibitors (read: free stuff!), tons of activities. Sensory overload. So pick your focus , but try at least one thing that will stretch you a little, socially and intellectually.

If you are new the conference, I highly recommend the First Time Attendee Orientation. At that session you’ll see everyone else who is wondering about the things you are and then some. The Early Registration Meet & Mingle and Ice Breaker Reception (Moscow mule, anyone?) is another great way to start the week. Between sessions, look up from your screen enough to meet some new folks and hang out. Dinner with New Agile Friends is a great way to meet people, especially if you are not attending with a group of colleagues. And, of course, the Conference Party should not be missed.

Don’t miss the Sponsors reception and the booths through out week. Check out our @VersionOne mobile photo challenge on Twitter where you can win daily prizes or a GoPro HERO3+.

Adapt
You’ll learn new things about the conference as you go through it. Your time is the most valuable thing to manage, with perhaps sleep a close second. Use the Open Space Law of Two Feet to adapt what you do. Is a session not quite what you expected? Don’t be shy, get up and move on. Take the time to find another session, hang out, catch up with those incessant emails and posts, or just take a breather (or nap)

Collaborate
You develop deeper understanding by interacting with others. The conference favors interactive sessions, but there are many other ways to share and learn. Be sure to swing by the Open Jam and catch the latest buzz. The Scrum Alliance is holding a Coaches Clinic each day where you can share ideas and challenges with Scrum experts. Our conference organizers, the Agile Alliance will have the Agile Alliance Lounge open each day.

And if you see any of us VersionOne folks, in our sporty shirts, please stop us, introduce yourself, and mention what a wonderful blog post this is. We love agile and learning by sharing with others.

Hangout
The most valuable experiences I hear about are the interactions people have hanging out in the hallways. These by-chance encouters lead to amazing insights and relationships. If you are are an extrovert, this will come naturally. If not, here are a few tips:

  • The Agile conference has always been known for its community atmosphere and approachable speakers and attendees. Its kinda who we are. So, realize that you are in an environment that specifically values Individuals and Interactions.
  • It may be awkward at first. Yes, it can feel very weird to approach someone you don’t know and initiate a conversation. Work to overcome that fear (for the XPers and Scrummers, this is living up to your Courage value). Asking about a favorite session or the basics like what one does in their job are simply ways to get a conversion started.
  • Don’t give up. Not every encounter will be amazing. If a conversation does not take off, no worries, the next one prpbably will.
  • Approach a group. If you hear a small group talking about a topic of interest to you, don’t hesitate to approach, express your interest in the topic and join in. You’ll be well received and add another interesting perspective to the dialogue.
  • You probably know more than you think. Many attendees have told me after the conference, “you know, from our experience, we know as much as most of the people at the conference.” If you are feeling intimidated that others seem to know more than you, realize that either a) they don’t and are just more comfortable talking about what they know or b) were in your shoes just a few years ago and are passionate about helping you learn what they’ve learned.

Do you have recommendations for conference goers? Please share them by commenting below.

Have a great conference. I hope our paths cross during the week.

Posted in Agile Coaching, Agile Development, Agile Management, Agile Portfolio Management, Agile Project Management, Extreme Programming, Kanban, Scaling Agile, Scrum Development | Leave a comment

Agile Software Needs Craftsmen

rock ridgeSo, you want to be an Agile shop.  You’ve read all kinds of cool stuff about Sprints, and WIP limits, and daily stand-up meetings.  You even think you get this crazy User Story and Planning Poker stuff.  You put together a room with snacks and lava lamps.  You have all of your stories in a cool ALM tool like VersionOne and displayed on a wide screen TV.  So you’re ready to go, right? Well….maybe not.  You are missing the most important part….the people.  Remember that one of the principles of the Agile Manifesto is to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In order to be successful, we need more than just motivated individuals, we need motivated Craftsmen.

Lets start with a disclaimer.  I use the term Craftsman in a gender neutral sense.  If folks feel like I should change this to Craftspeople, let me know and I will.  I get a lot of inspiration from the Software Craftsmanship movement, which tends to use the word Craftsman.

So what is a Craftsman, and what does that have to do with Agile?  Agile is hard.  It is a very highly disciplined approach to software development.  It also is very fast moving.  If we expect to be able to “welcome changing requirements, even late in development”, we need to have people with a high degree of skills in order to do that.  A craftsman is someone who takes the craft of programming seriously.  One who will not do garbage work, and will not accept garbage from her peers.  Lets take a look at the values delineated in the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

We’ve all seen these many times, but let’s now look at the Craftsman’s Manifesto.  You can find a link here: Manifesto for Software Craftsmanship

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

You-Complete-me

So really, they are symbiotic.  A well performing Agile shop will have Craftsmen as the vital part of their team.  A team of Craftsmen, by their very nature, will be embracing those values and principles of the Agile Manifesto.  So don’t forget the people as you build your Agile shop.  Create an environment that encourages those great practices like Test Driven Development and Continuous Integration.  Allow your team members the freedom to practice their craft, and the opportunities to enhance their craft.  In the end, you will have your motivated individuals who will delight in getting the job done.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Software, Agile Teams, Agile Testing, Agile Tools, Agile Training, Continuous Integration, Distributed Agile, Enterprise Agile, Extreme Programming, Iterative Development, Kanban, Lean, Lean Software Development, Scaling Agile, Scrum Development, Scrum Methodology, Scrum Software, Scrum Tools, Test Driven Development, Uncategorized | Leave a comment

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

WARNING: Shameless plug for my session at Agile2014 ahead.

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

DocFormula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Methodologies, Agile Teams | Leave a comment

With Me It’s All or Nuthin’

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Agile Tools, Continuous Integration, Enterprise Agile, Extreme Programming, Iterative Development, Scrum Development, Scrum Methodology, Test Driven Development, Uncategorized | Leave a comment

Lots of carryover? Try swarming

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | 2 Comments

Agile Beyond Software: A Manifesto For All Industries

Lean ManufacturingWhen the Agile signatories created the Manifesto, software was obviously at the core of their thinking, which makes sense as they were all building software at the time.  As it has grown in its popularity, however, Agile has gone beyond software.  So, should the original Manifesto be adjusted to accommodate these new adopters?

There is an ongoing debate about whether Agile is only for software development or whether it can be applied to other industries.  In order to even attempt to see if Agile could be applied, we should first take a look at the original values and principles, which you can find here: http://www.agilemanifesto.org.

With that, here is a stab at what it might look like if it were to change. I’ve underlined any text that has been altered from the original:

Manifesto for Agile Product Development

We are uncovering better ways of developing
products by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working products over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Here are the principles with changes:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable products.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working products frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working product is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Okay, so there it is.  Yep, it’s that simple, I just changed the word “software” to “product”. Maybe you think there could be issues with some of these values or the principles if they were applied to other-than-software production.  I’d like to hear your thoughts.  If you have other industry experience, would these be good to apply to your industry?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Marketing, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Kanban, Lean, Scaling Agile, Scrum Development, Uncategorized | Leave a comment

New ScrumMaster Tips

Team

I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology | 1 Comment