Friday, August 31, 2012

One Manager at a Time

By: Laura Althoff, Scrum Master and Executive Director of Scrum Inc.

Last weekend while catching up with my mom on the phone the topic of Agile arose.  I'd off-handedly let her know that I had presented at the Agile Boston monthly meeting, but this story prompted further explanation about user groups and Agile.

My mom is a seasoned college administrator with over 25 years managing a department of people around lots of time-sensitive projects and in conjunction with many other departments.  She doesn’t have any experience with software but she’s a quick learner and great conceptual thinker.  I gave her the 20-second overview of development in Waterfall and Agile environments and the role Scrum plays, which of course helped her understand my current job in a new way.  Her response:  “Wow.  From you I understood that Scrum helps teams work better together, but I’ve never heard of Waterfall or Agile.  How come the general public doesn’t know about how software is made when we all use it all the time?  And couldn’t I could use an Agile approach in my department?”  

Here were some great questions.  Let’s start with why the general public may not know more about the development process.  One thought is the language barrier.  The field of development, like most professional fields, is full of acronyms, jargon, and highly specific terminology.  It can be overwhelming and intimidating to someone outside it.  Regression testing, CMMI, continuous integration, TDD loop, 10-minute build, refactoring – what are these things?  Another thought is that people outside of development don’t really consider all it takes to make software and hardware. We expect our computers to just work and we may not care about the process it takes to do so.  Clearly, not everyone needs to know the language in another industry, nor do we need to know the ins and outs of exactly how it works.   But what if that industry were doing something that increased their competitive edge in the marketplace?  And what if that something had easy application beyond that industry? 

We know Scrum is widely-recognized and widely-utilized in development.  It’s where Scrum was born.  And in addition to being an effective frame in which to get stuff done, Scrum opens things up.  It has the power to make contained, insular systems, into transparent processes.  Anyone from the organization can see the burndown chart to know what the team is working on and how it’s progressing.  Better yet, customers (customers!) are invited to sprint demos to weigh in on the product and to make it better.  Next, by tracking the work so publicly, anyone can see how it works, and how useful Scrum’s application in any department or team of people who need to get something done could be.  How many times have we heard stories of marketing teams or HR teams or any non-Scrum team who say “Scrum seems to be working really well for that software team…why can’t we use it here?”

The great news?  You can.  And one of the best ways to help make that happen in any organization is by having a management team who understands what Scrum is and how it can impact their bottom line.  What management team wouldn’t want to get things done faster for less?   What management team would say no to hyperproductive teams?

Next month, managers get a special opportunity to hear from Jeff about why they specifically need Scrum and how it will help them capture the competitive edge.  Join us for the live webinar on September 26.  I’ve already registered one manager, who just happens to be my mom.

Thursday, August 09, 2012

GAO Report on Agile Practices in Government

The government is waking up to the incredible waste in federal software procurement. In 2000, a DOD study showed that 75% of $34B in projects was totally wasted. Ken Schwaber and I reviewed the Sentinel Project at the FBI in our latest book Software in 30 Days and found an even higher level of waste where an agile team in the basement of the FBI finished over 80% of the work in 10% of the budget after Lockheed Martin was issued a stop work order for their abysmal waterfall performance. An item was passed into law in 2010 requiring DOD to demand agile practices in procuring software. We have commented on this previously. As a result the Government Accounting Office is reviewing agile software practices and issued a new report.

Why GAO Did This Study
Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of
Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.

GAO Develops an Impediment List
Federal Agencies encountered problems implementing agile practices that are typical in commercial software development firms. Aggressive assessment and remediation is required.

Federal Agency Impediment List 
  1. Teams had difficulty collaborating closely.  
  2. Procurement practices may not support Agile projects. 
  3. Teams had difficulty transitioning to self-directed work.
  4. Customers did not trust iterative solutions. 
  5. Staff had difficulty committing to more timely and frequent input. 
  6. Teams had difficulty managing iterative requirements.
  7. Agencies had trouble committing staff. 
  8. Compliance reviews were difficult to execute within an iteration time frame.
  9. Timely adoption of new tools was difficult. 
  10. Federal reporting practices do not align with Agile. 
  11. Technical environments were difficult to establish and maintain.
  12. Traditional artifact reviews do not align with Agile.
  13. Agile guidance was not clear.  
  14. Traditional status tracking does not align with Agile
Virtually all of these impediments are directly related to inadequate management practices. For this reason we have developed a management workshop program at Scrum Inc. that provides training for managers in how to identify these impediments and develop strategies for removing them.

Friday, August 03, 2012

Announcing Scrumlab! Where To Get Answers On Scrum.

I've trained, at last count, some 7,000 Scrum Masters. That's a lot of change to unleash into the world, and the stories I hear are nothing short of inspiring. I also hear a lot of questions on every topic under the sun. I've done my best to answer them one on one, and I've written a 
few books that hopefully address some of them.  I also have a whole section of my website that recommends books by others that can answer a lot more.

But peole keep asking me about a reliable place online where they can go to learn more about Scrum, brush up their practice, share their stories, and learn from others. I'm pleased to announce the launch of Scrumlab - the place to go! It's still in its infancy, but I think we have a minimum viable product. There are forums where anyone can ask questions, anyone can share their thoughts, and where I, and the rest of the Scrum Inc. team, will be sharing our thoughts as well.
Do you have any questions about the Scrum Guide?
Have you ever wondered what others demo in the Sprint Review?
And we want to know about what you've done...what was the first thing you implemented after your Scrum Master class? And are there any questions you have now that you've been a Scrum Master or Product Owner for a bit? Ones that you wish you'd asked during the class?
Well, Scrumlab is the place to start. We're really excited about building a community of Scrum practitioners who can help each other do better Scrum, be more Agile, have more fun, and maybe change the world for the better. A little bit, anyway.
And this is just the beginning. Over the next couple months we'll have papers and patterns, handbooks and cheatsheets, videos, slides, and a whole host of other material I've been gathering for years and have finally have a good place to share it.

Time Tracking is Anti-Scrum: What do you do when you need it for billing?

In general, tracking hours slows teams down and confuses the Product Owner about release dates. Over 50 years of research shows that hours have high error rates and variability and relative point estimation is better. Even worse, some of our consulting partners bill in hours when they are hyperproductive and running at five times the production rate of waterfall teams on the same project. Yet they only get paid for the hours they work! They leave 80% of the money they should be getting on the table. This is very bad business management to negotiate contracts like this.

However, sometimes consultancies and even product companies find they have to bill in hours or collect hours due to unenlightened management. In this case, Scrum data can be collected in a way to give more accurate hourly estimation and completion than traditional planning. In the early years at PatientKeeper, we were experimenting with hyperproductive Scrum and wanted detailed hourly estimation. For several years, we gathered tens of thousands of data points until it taught us we could go faster with point estimation alone (at that time we abandoned any hourly tracking).

When we implemented an automated Type C Scrum back in 2002 at PatientKeeper, we did a user analysis of what to ask developers to minimize their administrative time (waste) and lean out the organization. I'm not aware of any other user studies of this type on eliminating administrative waste for developers.

We came up with a counterintuitive answer. While all we wanted to know was how to update the Burndown Chart, our developers told us not to ask about time remaining on a task for the following reasons:

1. It took more than 60 seconds to answer the question for five tasks and 60 seconds was the design criteria for the project reporting system.
2. It made them think too hard and they did not want to be bothered when they thought the resulting estimate was not necessarily accurate.
3. They felt that the estimate of time remaining had high variability and therefore was high risk. If the current estimate was exploding they knew what time they had invested and percent complete. Anything else was pure guesswork.

These were high powered professional engineers. We had several Ph.D.s on the team from MIT and elsewhere. The founders of the company were all MIT graduates. As a result, my view was that they gave the "right" answers to the questions based on best practice and not an answer you would get from inexperienced, perhaps ill-motivated engineers, who knew little about Scrum.

By taking the time invested and percent complete on each task touched each day, the system autocalculates time remaining to update the Scrum Burndown Chart. If a task is 50% done and one day is invested, the time remaining is assumed to be one day. The new total estimate for the task is two days. The original estimate for the task is archived in the system for historical analysis. The Burndown Chart automatically recalculates every estimate for every item touched during a day.

Time remaining to Sprint completion is all that is reported publicly and the team remains focused on what it takes to get "Done" at the end of the Sprint and does not even feel the questions asked relate to time reporting in any way. It is simply the "leanest" way to get the data needed to update the Burndown Chart.

A side effect of this approach is that consulting companies that bill customers on an hourly basis can generate billing from our automated system without filling out any time sheets.

It was generally agreed in a Scrum training class in Copenhagen yesterday with experienced project leaders operating at CMMI Level 5 at IBM and elsewhere that asking developers to fill out time sheets reduces team productivity by at least 10%. They hate to do it, it is duplicate work, it is obviously "waste", and is only done by companies that do not have a clue about lean product development. I have consulted at some companies where time reporting is so complex, developers make up time sheets, the company lies to customers as a result, and senior management make bad decisions on erroneous data, compromising the company's success in the marketplace. My final report to senior management was that 50% of their entire development productivity was lost because of the time sheet implementation.

Any project leader that has any sense will not "waste" 10% or more of development team productivity. They will move heaven and earth to avoid it and get more features done sooner with higher quality.

The recommendation to software development organizations that have to bill hours is:

1. Abolish all time reporting.
2. Institute the part of Type C Scrum reporting described above. You do not have to implement a Type C Scrum to do this. How to do it is detailed in the current draft of the book, "The Scrum Papers." For those willing to give editorial feedback, send me email and a copy of the latest draft will be made available.
3. Autogenerate time reporting to the customer from the Type C Scrum approach. Never use it to report development progress.
4. This approach gives more accurate information than any time reporting system ever created:
- Developers never "make up" the data on the time sheets.
- Exact time is available for every task.
- It provides a "micro-costed" analysis of work in progress.
- You never lie to customers. They are billed only on real work.

For those organizations not billing in hours, we recommend abandoning time tracking completely and go to only relative point estimate. 

Teams that do this have more accurate estimates and higher velocity. See why story points are better than hours.