Posts Tagged ‘SCRUM’

Methods, Practices, and Outcomes

Posted on September 1st, 2009 by Dennis Stevens  |  No Comments »

There continues to be discussion about Scrum (as a brand) vs. Kanban (capital K) vs. Crystal vs. FDD, etc. If fact, I received a comment today on a March post discussing the Scrumbut test. My comment became to long and is so relevant to recent discussions that I turned it into a blog post. From my perspective these method wars tend to fall into “How Trap” discussions. How Trap discussions are not about specific outcomes you are trying to achieve and developing a situationally specific approach to achieving those outcomes.

Take a look at the Scrumbut test I learned about from Jeff Sutherland. Whether you are doing (or even like) Scrum – when viewed through an outcome lenses, these questions lead to discussion regarding clearly important outcomes. Below, I list the question category from the Scrumbut test, then the outcome that is desired from the practices described in the Scrumbut test, then a hopefully clarifying description.  The practices are detailed at the Scrumbut link.

Question 1 – Iterations: Limit Work in Process – don’t start anything you can’t finish

Question 2 – Testing within the Sprint: Maintain Code Quality – Shorten quality feedback loops to zero to maintain code quality and reduce the waste of rework

Question 3 – Agile Specification: Communicate Business Needs to Development – Ensure developers understand outcomes while minimizing coordination and transaction costs, maintain traceability to business need

Question 4 – Product Owner: Maintain Product Roadmap – The business communicates a plan of what is being built

Question 5 – Product Backlog: Prioritize Investments Based on Return – the business prioritizes work based on a current understanding of business value

Question 6 – Estimates: Provide Meaningful Effort Estimates – Understand rate the team can produce work to support planning, investment decisions, and customer commitments

Question 7 – Burndown Chart: Communicate Release Schedule – Be able to predict content and timing of future releases. This clarifies corrective action, next most valuable investment decisions, marketing decisions and customer commitments

Question 8 – Team Disruption: Maintain Productive Work Environment – Management understands and supports the focus on rapid delivery. Trust is established that the team will be able to meet current and future commitments.

Question 9 – Team: Develop an Empowered Team – The team feels empowered to make decisions about how to move forward. Management has provided sufficient guidance and direction that they trust the team will make operational and tactical decisions aligned with the best interest of the business.

Yes, Jeff has a brand he is protecting. If you think you are doing Scrum and you aren’t achieving these outcomes then you aren’t doing what was intended. Bad Scrum and Scrumbut hurts the Scrum brand. In fact, since Scrum is a dominant Agile brand, it hurts all of us trying to move Enterprises towards improved software agililty.

But, Scrum isn’t the only way to achieve these outcomes. I can map these outcomes to mature implementations of XP, DSDM, FDD, Crystal and Kanban (etc.). Now the interesting conversations sound like –

  • In what situations does Kanban reduce transaction and coordination costs more than Scrum?
  • In what situation does one method lead to better adoption over another? Why?
  • In a specific organization, what approach to developing empowered teams and upstream trust will be most likely to succeed?

The outcomes described in the Scrumbut test can be achieved by applying specific strategies that are consistent within an organization’s environment. When these outcomes are adopted development teams tend to become more mature, better at delivering software (many times dramatically), and improve their work environment. Regardless of method, you need to be focused on the outcomes that result in improvements in productivity and find the way that works in your organization to adopt and sustain the outcomes.

PMI Agile – Debate or Learning Opportunity?

Posted on August 10th, 2009 by Dennis Stevens  |  13 Comments »

Vasco Duarte over at Software Development Today has launched a grenade at the PMI Agile organization with his post PMI vs Agile, what is different, and why you should care.  He was responding to Lynda Bourne’s post Agile: The Great Debate. I started writing a comment that became really long so I decided to put this up as a blog post.

First, I must admit to having an advantage over Vasco in that I know Lynda Bourne. She is a talented and smart project manager who focuses on issues of engaging people in the right way. People in the Agile world would appreciate her sense of humor, empathy, and focus on treating people the right way. I don’t know Vasco. I like what he says on his blog for the most part, I see his tweets and comments on Twitter, and I think he is an intelligent experienced guy with a valuable point of view.

This conversation fascinates me for a number of reasons. First, one of the tenets of Agile is to value people and interactions over processes and tools. This manifests itself in respect for people and learning. One of the things I teach in my project conversation work is the importance of holding the other person as valid – believing what they have to say matters. Yet in this Agile vs PMI conversation there is a lot of not holding the other person in a very positive light. Another is seeking first to understand, the common approach is to point out what is wrong with the other persons world.

In her post, Lynda points out that there are three areas for discussion between PMI and Agile.

  1. How do Project Management practices differ when interacting with Agile development vs. Waterfall development?
  2. Can traditional Project Management learn from Agile?
  3. What triggers choices between operational maintenance, development and projects and waterfall vs agile techniques.

I think these are good points for traditional Project Managers to understand as they make decisions about how to support a project with an Agile software component.

Vasco took offense about two points Lynda made in the first question regarding a PM moving to Agile from Waterfall. Remember as you read this that she is writing on PMI’s website to PMP’s.

  • The need for robust change management and configuration management to track the evolution of the Agile project
  • The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Vasco says these points reflect a lack of understanding at PMI regarding Agile. He claims her explanation to PMP’s that Agile projects have a strong dependency on change management and configuration management indicates she has no understanding of Agile. However, her reference to change management is in the same sentence as one to configuration management. She is absolutely referring to code. Since many PMI managers aren’t software development manager’s they likely don’t understand the critical nature a robust CI/CM infrastructure. In fact, many “agile” projects fail to implement these and this leads to project disasters. I feel her point is completely valid and Vasco’s retort is not helpful.

Vasco then says she is asking for BUFD. She didn’t say you need a Big Up Front Design. She said you need an Architecture and a strategy for delivery. Even the link Vasco refers us to agrees with Lynda. The first slide asks, “Architecture is a heavy-weight activity, and the magic of Agile makes it unnecessary to bother with up-front design, right?” Their response is, “False.” The presenters point out that this is a common misconception even among Agilists. I believe that Vasco’s retort reflects a bias against bad PM he has faced and does not reflect the validity of Lynda’s post.

Agile (Vasco refers specifically to Scrum) is about Software Development. In most organizations, software development is about 25% of the solution. People, processes, and management practices have to be addressed as well. And not just within the development and delivery of software, but across the entire organization. Project Management deals with this bigger world. The big opportunity is to learn from Agile how to align with and improve delivery outside of software and how to support Agile so the development team can deliver value to the organization with a minimal amount of friction.

I am not suggesting that PMI and all PMP’s have a clear understanding of Agile and how to implement it. I agree that there is a lot of discussion that needs to be held to make the two perspectives meet. I do think it is important that the perspectives meet. PMI is reaching out to the Agile community. They are making an attempt to understand and be understood. There is also a real need for us to bring these areas together in a way that drives value through our businesses.

Uncovering Better Ways of Developing Software by doing it and Helping Others do it

Posted on July 12th, 2009 by Dennis Stevens  |  4 Comments »

In the Agile Manifesto it says, “We are uncovering better ways of developing software by doing it and helping others do it.” I have been paying attention to the conversations between the BUFD traditionalists, the Agilists, and now the Kanban communities. This conversation has not always been friendly – and some members of each community certainly aren’t looking to learn about better ways of developing software. In fact, the contentious debates are creating obstacles to helping others do it.

I find that there are valuable capabilities in each of the practice areas. Agile was never completely different than BUFD. It was 20-30% different. And that difference, when done well in the right context, dramatically improved the value of the software being developed and the velocity that it was delivered. Kanban is probably 10-20% different than Scrum, the most prominent instance of Agile. XP doesn’t really come into the discussion because XP practices will be applied in both of the situation. In the right context, Kanban will deliver dramatically improved value and velocity over explicit Scrum. After all, some companies have moved to single-unit engineer-to-order flow over small batches and realized dramatic improvements.

As I have been wrapping my brain around the distinctions and benefits, I keep coming back to Gerald Nadler’s book from the mid 1990’s, Breakthrough Thinking: The Seven Principles of Creative Problem Solving. Nadler had developed a meta-model for problem solving (solution finding) that has consistently delivered dramatic results. I am going to share the seven principles with you and then use them to talk about why I think the principles in Kanban can deliver results that are better than teams doing Scrum.

1. Uniqueness: Every problem is unique. You can’t directly copy a solution from elsewhere. Only if the context of the purposes shows it is useful should some available solution be considered.

2. Purposes: Always and continually ask the purpose. Then ask the purpose of that purpose. Expand as far as possible with this exercise. Focusing on purpose lets the uniqueness of the situation become clear and strips away nonessential aspects of the problem context.

3. Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution of the future. Having a target solution I the future gives direction to near-term solutions and infuses them with larger purposes.

4. Systems: Employ a format that includes all elements and interrelationships that the target solution will entail. Every solution or system is part of a larger system, and solving one problem inevitably leads to another. Understanding the elements and dimensions that comprise a solution lets you determine in advance the complexities you must incorporate into the implementation of the solution.

5. Limited Information Collection: Before taking the time and wasting the effort to collect and analyze extensive data, determine what purposes would be achieved by gathering the data. Study the solution, not the problem.

6. People Design: Throughout the process of finding a solution, give everyone who will be affected by that solution the opportunity to take part in its development. People are willing to explore purposes and solutions-after-next, rather than to gather data about what is wrong with the current system. Those who carry out and use the solution should be intimately and continuously involved in its development. Also, the proposed solution should include only the critical details, in order to allow flexibility for those who must apply the solution.

7. Betterment Timeline: Even as you design today’s solution, schedule future changes necessary to its continuous success. The only way to preserve the vitality of a solution is to build in and then monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to a better future.

Scrum explicitly calls out several of these principles, particularly uniqueness, purposes, and people design. It provides direction that you should be looking for a way to remove impediments. It doesn’t explicitly provide guidance for doing that and a good, experienced manager is already applying many of the other principles. As I was telling Mike Cottmeyer this morning, a Scrum team in the right context will (and have) evolve into (many of) the Kanban practices.

Kanban explicitly calls out the rest of these principles. The Kanban itself becomes a framework for understanding the System and focusing on just enough information. The operations review is specifically in place to establish a betterment timeline and the solution after next.

Most of the Scrum teams dislike management and the other functional groups they interface with. The concept of pigs and chickens and the common perception that management causes obstacles for the team lead to conflict and distrust. Kanban focuses on how the development team can work better across the organization. From a purposes focus and people design standpoint, the Kanban perspective leads to greater trust and a shared focus on the solution-after-next.

Finally, many Scrum teams struggle with how to schedule defects and rework into their iterations. In the iteration world, QA gets the release after the end of the iteration for acceptance testing – this creates delay in feedback. This delay leads to all the relearning problems that we all have discussing. The enforced reduction in work in process and the single-unit flow reduces rework and shortens the time to feedback on defects and acceptance issues.

According to most reports, we still aren’t great a reliably delivering technology. No one has an answer yet that works for everyone. There is a lot of room for improvement and I believe we need to keep an open mind as we uncover better ways of developing software by doing it and helping others do it.

Reducing Multi-tasking: Key to Productivity

Posted on April 23rd, 2009 by Dennis Stevens  |  No Comments »

Mike Cottmeyer has also been talking about scaling Agile. In his recent post on Second Order Agile Scaling he talks about how important it is to reduce the number of active projects in the portfolio. In other words, the goal is to focus on finishing projects as fast as possible, not on starting them faster or keeping your resources busy. When the organization has too many active projects at a time, it overloads the system and actually slows down delivery. You will see this when you have too many applications open on your computer. One application runs fast. Two probably still run well. But if you open ten or more applications, all of them slow down.

 In the last year I have seen a company with almost as many active projects as IT resources. Another company had the philosophy to start projects early so they wouldn’t get cut when the budgets were revisited. Not surprisingly both of these companies are late and over budget on almost every project. This is not a talent or process problem, it is a scheduling problem. When you overload the system, the resources start multi-tasking. My friend Steve defines multi-tasking as the intentional stoppage of ongoing work to transition focus to another task area. This is a bad plan. You want to avoid overloading the system with multi-tasking.

I have written about Multi-taking before. Several of my favorite bloggers have also discussed multi-tasking. Reforming Project Management, Focused Performance, and Clarke Ching often explain the dreadful impact of multi-tasking. Multi-tasking is bad for a number of reasons. I am drawing on my post at http://blogs.synaptus.com from March 2007 to discuss four of them here in the context of the current conversation.

One: Starting sooner doesn’t mean you will finish sooner.

Let’s say you have three people that want you to do something. To simplify this example, each thing takes three days to perform. You want to make everyone happy so you start working everything as soon as possible. You switch between them each day to continue to show progress on each thing. So your work looks like this.

Scenario 1: ABCABCABC

You deliver “A” on day 7. “B” on day 8. And “C” on day 9.  In trying to make everyone happy, you pushed A and B back and didn’t do C any favors. If you had worked on these things in sequence, your work would look like this.

Scenario 2: AAABBBCCC

You deliver “A” on day 3. “B” on day 6. And “C” is still delivered on day 9. Starting sooner didn’t get work done sooner.

Two: Sometimes work needs to be expedited.

It just happens. In Scenario 2 above, you could just drop the expedited work into the queue as the next thing to do. You don’t interrupt other work in progress, and you will finish it just as fast as possible. Remember, starting it as soon as possible isn’t what’s important. Finishing it as soon as possible is what’s important. Mixing expedited work into the middle of the flow will slow everyone down. Because it takes an incremental approach and working software is delivered at the end of each iteration, Agile development enables this much better than BUFD projects.

Three: Customer requirements change over time.

When you take longer to deliver work, you raise the risk that the customer requirements will change.  You want to have the shortest amount of time from when the work starts to when the work is delivered to the customer. This will reduce the risk that the customer requirements will change on work in progress. When customer requirements change on work in process, it creates rework. Rework is extremely expensive.

When you run in an Agile fashion, you will schedule epics (or big features or capabilities) into the pipeline well in advance. You have an Order of Magnitude estimate of time and cost, a general idea of what problem it addresses, and a perspective on the value of the epic (or big feature or capability) that you use for prioritization. You don’t do the detailed requirements and design until just before you drop it into the pipeline to be built. This shortened time reduces the risk that the customer will change the requirement.

Four: Task switching is expensive.

As this NY times article points out, we are not effective at getting back to productive work when we are multi-tasking. One of the tenants of lean is to eliminate waste. There are Eight Wastes defined in Lean. Multi-taking directly contributes to six of these wastes. We create Defects from forgetting what we were doing. We create Inventory from work piling up when we switch away. We create additional Processing from having to put away work and then find it again. We create Waiting (interruption of flow) and then the customer forgets what they asked for or their requirements change. We create Overproduction because we have more work started then the system can efficiently process. Finally, we create Non-Utilized Talent through the stress that is created for the developer who is always behind and having switch between tasks. Multi-tasking is a bad investment.

Following an Agile approach increases productivity because it specifically focuses on reducing these wastes. This is not accidental. When I took the Certified Scrum Master class from Jeff Sutherland he said that among other things they had intentionally drawn on proven concepts from Lean. 

Excessive multi-tasking derails productivity.

Our work lives are probably impacted by most of these issues – often in combination. The multiplying effects of multitasking are devastating to performance in organizations. You can have the right people, the best processes, and a solid strategy. Multi-tasking can derail the productivity of the group. Fixing this problem can double the productivity of a work group. In reality, you can’t eliminate multi-tasking completely. This is a complex problem to address but it is worth the investment. Taking an Agile approach to work, prioritizing completion of work over starting work, and intentionally coordinating work across functions with the intention of reducing multi-tasking are the first steps.

We’re Doing Scrum But…

Posted on March 5th, 2009 by Dennis Stevens  |  12 Comments »

I come from a big project, high ceromony background. I learned Software Engineering as contractor at IBM in the 80’s, was a Marine, and believe in the PMBoK (Deputy PM on OPM3® Second Edition). Over the last 10 years I have studied and learned Agile from books and through mentoring relationships. I have applied what I understood and have experienced improved performance. But I still thought of Agile/Scrum as a less than responsible way to do work.  I have heard a lot of push back on Agile and Scrum in blogs and on Twitter lately. “Scrum doesn’t work”, they are saying. “Scrum makes the devleopers life easier but hurts the customer”, is another one. “The lack of overall budget/timeline is a killer (only look 1 sprint forward, really)”, is a charge hurled this week. 

Last week, I went to the source and completed Jeff Sutherland’s Certified Scrum Master course. During the training with Jeff Sutherland last week, he presented a ScrumBut test. We are doing Scrum but… means you aren’t doing Scrum. Not doing Scrum means you likely won’t get the benefits other teams that are doing Scrum have claimed. Scrum, when done well, is a responsible way to develop software and if positioned maturly is a benefit to management. With permission from Jeff, here is the ScrumBut test. Take the test, add up your scores and divide the result by 9. 

Question 1 – Iterations

- No Iterations – 0
- Iterations > 6 weeks – 1
- Variable Length < 6 weeks – 2
- Fixed iteration length 6 weeks – 3
- Fixed iteration length 5 weeks – 4
- Fixed iteration length 4 weeks or less – 10

Question 2 – Testing within the Sprint

- No dedicated QA – 0
- Unit tested – 1
- Feature tested – 5
- Feature tested as soon as completed – 7 
- Software passes acceptance testing – 8
- Software is deployed – 10

Question 3 – Agile Specification

-No requirements – 0
- Big requirements documents – 1
- Poor user stories – 4
- Good requirements – 5
- Good user stories – 7
- Just enough, just in time specifications – 8
- Good user stories tied to specification as needed – 10

Question 4 – Product Owner

- No Product Owner – 0
- Product Owner who doesn’t understand Scrum – 1
- Product Owner who disrupts team – 2
- Product Owner not involved in team – 2
- Product Owner with clear product backlog estimated by team before Sprint Planning meeting (READY) – 5
- Product Owner with a release roadmap with data based on team velocity – 8
- Product Owner who motivates the team – 10

Question 5 – Product Backlog

- No Product Backlog – 0
- Multiple Product Backlogs – 1
- Single Product Backlog – 3
- Product Backlog clearly specified and prioritized by ROI (business value) before Sprint Planning (READY) – 5
- Product Owner has release plan based on Produce Backlog – 7
- Product Owner can measure ROI (business value) based on real revenue, cost per story point, or other metrics – 10

Question 6 – Estimates

- Product Backlog not estimated – 0
- Estimates not produced by team – 1
- Estimates not produced by planning poker – 5
- Estimates produced by planning poker by team – 8
- Estimate error < 10% – 10

Question 7 – Burndown Chart

- No burndown chart – 0
- Burndown chart no updated by team – 1
- Burndown chart in hours/days not accounting for work in progress (partial tasks burn down) – 2
- Burndown chart only burns down when task is done (TrackDone pattern) – 4
- Burndown only burns down when story is done – 5
- Add 3 points of team knows velocity
- Add two points if Product Owner release plan based on known velocity

 Question 8 – Team Disruption

- Manager or Project Leader disrupts team – 0
- Product Owner disrupts team – 1
- Managers, Project Leaders or Team Leaders telling people what to do – 3
- Have Project Leader and Scrum roles – 5
- No one disrupting team, only Scrum roles – 10

Question 9 – Team

- Tasks assigned to individual during Sprint Planning – 0
- Team members do not have any overlap in their area of expertise – 0
- No emergent leadership – one or more team members designated as a directive authority – 1
- Team does not have the necessary competency – 2
- Team commits collectively to Sprint goal and backlog – 7
- Team members collectively fight impediments during the sprint – 9
- Team is in hyperproductive state – 10 

My best recent project scored a 6.7 on this test and we didn’t call it Scrum – we just considered it responsible management of an analytics projecyt. We did perform really well in a tough situation though. If you score less than a 6 on average, you probably aren’t doing Scrum. That may be good or bad – but if you aren’t doing Scrum, don’t call it Scrum. If you aren’t performing at a hyperproductive level, look at the areas where you didn’t score as well. It is likely they will highlight the next most important impediment for you to focus on removing. Fix that and move forward.

The Role of Conversations in Projects

Posted on March 4th, 2009 by Dennis Stevens  |  1 Comment »

This is a slightly updated presentation of a talk I gave at Atlanta’s Project Developer Days a few years ago. After attending a two day training session with Jeff Sutherland, I believe that this concept is relevant to the Agile and SCRUM Project Management conversation.  From my experience, improving the performance of the conversations on your projects greatly improves the performance of the project team. When we say we want to get better at communications, I believe we want to improve the quality and effectiveness of the project conversations. The project managers job in leading projects requires us to be good at recognizing what conversations need to take place, and facilitating them to a successful conclusion.

Regarding the Blind Men and the Elephant

Posted on March 3rd, 2009 by Dennis Stevens  |  3 Comments »

If you aren’t familiar with the story of The Blind Men and The Elephant it is about six blind men that go to study an elephant. When they come back, they all report on the elephant in different ways. They variously report they found a wall, a spear, a snake, a tree, a fan, and a length of rope. They argue to defend their perspective. The discrepancy lies in the fact that each studied a different part of the elephant. The poem and the related illustrations at the link above demonstrate the story very well. The story is a metaphor about how we see the world from our individual perspective and have a difficult time understanding the bigger picture.

Delivering software and technology is a lot like that elephant. Over my career, I have been the blind man trying to figure that elephant out. I wrote code for the first decade, then began to study what great code and then architecture looked like. I joined user groups and associations and studied the engineering practices around software development. I studied function point counting and became a member of IFPUG. In the mid 1990’s Senge and Ackoff seeded my Systems Thinking perspective. My work at Perot Systems shaped my Business Process Re-engineering perspective. My degree is in Organizational Psychology and Development and I have been fascinated with the role language, knowledge creation, and team dynamics play in this area. I first read “The Goal” and “Critical Chain” in 1998 and have studied and applied the TOC thinking processes and CCPM to project scheduling. I have been greatly influenced by Theory of Constraints thinking. I have been around Agile development for over 10 years. I have a bookshelf full of eXtreme Programming and Agile books. I am also very involved with the project management institute as well, earning my PMP in 1998 and I spent the last couple years as the Deputy Project Manager of the Organizational Project Management Maturity Model - OPM3®.   I earned my Lean Value Stream Mapping certification from the Lean Enterprise Institute in 1999.

In each of these cases I went into the community trying to learn what they had to offer and figuring out how to responsibly help companies profitably deliver technology. One of the interesting things I have consistently observed is the disdain these communities hold for most of the other communities.  I was at an Architecture conference in 1991 where the various OOAD people were actually yelling about the best way to identify objects for a system. The TOC and Agile people really dislike the PMI people. Even inside the Agile community, the Lean and Agile groups are at each other’s throats. Engineers discount the human elements and the softer side of team dynamics.  Everyone is arguing for the importance of their view of the elephant. High ceromony scoff at the lack of maturity of the low ceromony while the low ceromony ridicule the waste of heavy and useless process and artifacts.

The problem is that the answer is not one particular part of the elephant. No one is completely right. We need to optimize the entire elephant and turn it into a sleek and agile race-horse. The battles between whether the elephant is a tree or a fan or a snake are not productive. They obscure the path to improving the ways that we can responsibly and profitably deliver value to our customers.

I spent last week at a course with Jeff Sutherland, one of the creators of SCRUM. The SCRUM he talks about is different than what I have seen on many SCRUM teams or read in books. Jeff incorporates aspects from Theory of Constraints, and Lean, and Knowledge Management. He promotes the items in the Agile Manifesto but incorporates elements from everything he has learned and observed. Jeff is trying to build a “big-tent” approach that brings responsible practices together while increasing performance and developing hyper-productive teams.

I encourage each of us to recognize our myopia in understanding this elephant. Try to understand the basic principles behind each practice and idea. Let’s agree that the way organization’s identify, manage, create, and deliver technology to organizations and customers is insufficient and put a lot more energy into improving. Technology plays a very important role in our economy today. We can’t get good enough fast enough right now, and dogmatic wars are too costly. What can we be doing to rapidly cross-pollinate and greatly improve our ability to profitably deliver value to our customers?