If you’re spending time at your stand-ups talking about activities you are working on, you may be wasting time. One team used to say things like:
“Yesterday I worked on the new Java class for our product and today I will be doing the same. No impediments.”
When you hear a similar song from others and it has been going on for a few days you know something is not right.
We changed the language and it made a difference. We stopped asking what we were doing, and focused on what we accomplished.
“Yesterday I coded the methods for the new Java class and completed half the unit tests we defined. Today I am completing the unit testing and connecting with Emily to prepare for system and acceptance testing.”
The difference is subtle but for some teams, like this one, the impact is big. Accomplishment is about outcomes. Working is about activity. Accomplishment is better.
A short while ago I was nominated to run for the board of directors of the Scrum Alliance. I wrote up the position statement that was requested for the first round. I had some trusted colleagues give me input and some of them reviewed what I wrote. I submitted it. Then I was notified I made it to the next round and was asked to submit another, updated write-up that will be posted for Scrum Alliance members to vote on.
The process got me thinking about the future of Scrum Alliance.
Will it exist ten years from now?
What will it look like?
How will it be perceived?
Will members and others view the Scrum Alliance as a trusted partner with cutting edge innovation and research and resources to match?
What will the next generation of product development teams need?
How will they interact with Scrum Alliance?
What will trainers and coached bring to the table that is innovative, fresh, and relevant?
These are the questions on my mind. But this represents only a singular view.
So I am curious. What do you expect to see from the Scrum Alliance in the future? What questions are on your mind?
I’ll be presenting “Cultural Architecture” at the Agile2011 Conference in Salt Lake City this August. Here’s an overview of the talk.
If our business culture was a product, how would we re-architect it? Culture influences everything. So how can we influence culture? What tools help us understand cultural influences, from the implicit, the elements we don’t even think about, to the visible, the artifacts that lead to stereotypes? Adopting an Agile culture, when it is under-laid with the cultures of the world is challenging. Reconciling cultural dilemmas drives collaboration and innovation. Culture is the core of it all. Knowing this, you can create a pull for cultural change in your organization.
For Agile veterans, this list of failure reasons is not new. But it never hurts to be reminded of what they are. So here is the list by Clinton Keith and Mike Cohn. I wish everyone would read this list and post it on their bathroom mirrors. You can find the source document here.
Don’t trust the team or agile. Micromanage both your team members and the process.
If agile isn’t a silver bullet, blame agile.
Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
Undermine the team’s belief in agile.
Continually fail to deliver what you committed to deliver during iteration planning.
Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily stand-up.
Don’t communicate a vision for the product to the team or to the other stakeholders.
Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
Replace a plan document with a plan “in your head” that only you know.
Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.
Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
Drop and customize important agile practices before fully understanding them.
Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
Don’t continually improve.
Don’t change the technical practices.
Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.
This is a follow-up post to Dinner with Jeff Sutherland, where Jeff talked about Systematic and the two LEAN metrics for driving improvements; 1) Process Efficiency, and 2) Fix time after failed builds. More details are now available in a paper titled Mature Scrum at Systematic.
Systematic combined a LEAN operating model, SCRUM as the project management framework allowing for flexibility and adaptability, and CMMI to institutionalize these elements into the culture of the organization, driving discipline and measurability. More information as well on how User Stories are prepared to a READY-READY state before being allowed to enter the Sprint. The grooming of the backlog and preparing User Stories is done in parallel to the Sprint.
Monday, March 29, I had the opportunity to have dinner with Jeff Sutherland and other RTP leaders. The dinner was a fundraiser for CITCON, which came to RTP in April. This was an opportunity for Agile practitioners and experts to have an informal chat about the challenges and opportunities of using Agile in the world of work.
I was interested in learning more about Systematic, a CMMI level 5 company that implemented Scrum across its entire business. One thing that sets Systematic apart from other companies is that it has really good data to prove that Scrum works, and it is a software company that can execute perfect waterfalls every time. Systematic created hyper-productive teams, and by Jeff’s definition, they are at least 4 times more productive than industry average. They cut TTM in half and the development costs by the same as well.