Orlando Scrum Gathering - Brief Recap

I just returned from two days at the Scrum Gathering, and enjoyed every minute of it.  I've attended quite a few conferences, but I thought this one was quite special for several reasons:

• PMI executives Greg Balestrero, CEO and Mark Langley, COO were in attendance as special guests of the Scrum Alliance.  Greg delivered the keynote address on the first day and stressed his committment to breaking down the barriers and enhancing collaboration between the PMI and Scrum communities.  I thought it was an important step in bringing the two communities closer together.
• Ron Jeffries and Chet Hendrickson eminently represented the XP community.
• Alistair Cockburn teamed with Ken Schwaber on a "duet" session.  Incidentally, Alistair is now a Certified ScrumMaster trainer.
• As part of the PMI Agile forum, I presented along with Michele Sliger, Jesse Fewell and Dave Prior.  My session was titled, The Agile PMO: Scaling Scrum through Adaptive Governance.  You can download a copy of my presentation here.

Another special opportunity was getting to see the launch of the space shuttle - picture is on the right.  As you might guess, I'm a fan of the management methods that NASA used back in the day -- see this Blog post for an example.

WEBINAR: Agile Metrics for Senior Executives

Is, “you can’t manage it if you can’t measure it” true for Agile?  Metrics definitely drive behavior, and with Agile methods, team members undergo significant behavioral change.  Appropriate selection of driving metrics is therefore one of the most important jobs for the agile management team. Without an appropriate set of Agile specific metrics, adoption efforts are likely to fail due to the mismatch between what we are measuring and how we actually want people to behave in this new environment. 

Join Roland Cuellar and me on April 15 from 12:00 to 1:00 EST as we discuss Agile appropriate metrics at the customer, portfolio and project levels in this webinar.

Title: Agile Metrics for Senior Executives

Date/Time: April 15, 2009 12:00 - 1:00 EST

PMI Agile@Orlando Scrum Gathering

Next Tuesday, March 17, 2009, I'll be speaking at the Orlando Scrum Gathering under the auspices of the PMI Agile forum.  This is an exciting step in the exploration of how the Agile and PMI communitites can interact for mutual benefit.

Besides the PMI Agile group, the Scrum Alliance Board has also invited PMI's executives Greg Balestrero (PMI President/CEO) and Mark Langley (EVP/COO) as distinguished guests.  Greg will also be delivering a keynote presentation on Monday.

Per Jesse Fewell, here a snapshot of the PMI sessions at the Scrum Gathering.

 

Date	Time	Scrum Gathering Event	Location
Mon 3/16	12:00 – 1:30	View From PMI by Gregory Balestrero	Osceola Ballroom C
Mon 3/16	3:30 – 5:00	Relating PMI's PMBOK Practices to Scrum by Michele Sliger	Tampa 2
Mon 3/16	3:30 – 5:00	Scrum in the Waterfall by Dave Prior	Osceola 4
Tue 3/17	10:30 – 11:30	PMI Agile General Membership Meeting	Daytona 1
Tue 3/17	3:00 – 4:00	The Agile PMO: Scaling Scrum through Adaptive Governance by Sanjiv Augustine	Osceola 1
Wed 3/ 18	10:30 – 12:00	PMP? ScrumMaster? So what's the difference? By Jesse Fewell	Osceola 2

If you're at the Gathering, please do try and catch one or more of the above sessions.

Scheduling in Scrumban

Recently, I wrote a short piece on Scrumban agile processes entitled "Moving To A Batch Size of One". This piece was responded to by some (thanks David!) with concerns about planning and scheduling, or the lack of apparent planning and scheduling in this ScrumBan system which I will briefly address now. In Scrumban, we eliminate iteration planning and instead implement a system of continuous rolling-wave planning. Let's say that a team has four simultaneous workstreams: large new features, small new features, large maintenance activities, and finally smaller maintenance activities. As new requests arrive into the team on an almost daily basis, which is common in many organizations, the team does a quick assessment and sizing of the request and figures out which workstream the request goes into. Our product owner will prioritize the activities for the team as usual so they know exactly what needs to be done next. With some simple metrics, we can soon track velocity around the four workstreams so that the team will know that on average:

1. It takes 3 days to deliver a small maintenance request +/- 1 day.
2. It takes 10 days to deliver a larger maintenance request +/- 2 days.
3. It takes 5 days to deliver a small new feature +/- 2 days.
4. It takes 15 days to deliver a large new feature +/- 3 days.

Through these simple metrics and a continuous planning system, the team can make pretty accurate commitments and never have to stop the production line for iteration planning. With continuous flow, we do not have to figure out exactly how much work will fit within an iteration because there are no iterations; just a continuous flow of delivery to customers. This may not be an appropriate system for all forms of development, but for some shops with a constant flow of new requests and ever changing priorities, this may be a potential solution.

When Should A Process Be An Art?

There is a great article in this month's Harvard Business Review entitled "When Should a Process Be Art, Not Science?" The idea here is that process standardization can go too far, particularly for products that are as much art as science. The article sites such endeavors as building Steinway pianos and software development as potentially artistic processes that will need different forms of management, metrics, and process definition from those of more traditional, repeatable activities. Artistic processes, the article says, are those that have great variation in both process inputs and process outputs and thus must be built by craftsmen who use considerable judgment and experience to create a final product that is suitable for a particular customer. So how should managers lead artistic processes? Through investing in skills, culture, training, and through frequent iteration and customer-based feedback loops. Furthermore, the article mentions that science can serve art by creating a basic and stable process foundation upon which the artistic endeavors of activities like software development can flourish. Of course, we in the Agile community have been supporting these ideas for years; moving away from heavy, overly prescriptive processes and more towards lighter weight, iterative frameworks, and company cultures that support the true nature of software development. For more, see the article here at HBR.