Last week I presented a talk on Co-creation at Agile2013. It was well received and at least for me, made it clear that co-creation is a challenging topic that requires intestinal fortitude to execute successfully.
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?
Catherine Louis of Cll-Group and I will be facilitating a three hour workshop at Agile 2012 in Grapevine Texas on Monday August 13. The topic; Modeling Large, Complex Agile Organizations. Over the past year and a half we have been developing and refining a modeling method that allows teams to create “preto-types” of their organizations to test ideas and solicit feedback rapidly on what might be an appropriate organizational design for a business given different types of constraints. Below is a reproduction of the abstract for our workshop.
In large geographically distributed organizations where the size of the product exceeds what a single Scrum team can build, we think through the best way to organize teams and work. Over the past year, we have been working with large projects (over 100 people), distributed in several countries and helping them develop organizational models that they can use to visualize how teams and work could be best organized to maximize agility. In this workshop, we guide the participants through the process of assessing and developing large organizational models. The models provide business stakeholders with a tool to assess the trade-offs of different organizational models visually and rapidly. Whether you are responsible for building a large scale global Agile organization, or are a team member with ideas on how to organize teams and work, this workshop provides you with tools to develop organizational “preto-types” to use for communication and troubleshooting large-scale Agile organizational design.
We invite you to join us at Agile2012 on the Adoption and Transformation Stage and take part in a highly interactive and fun workshop. Complete details can be found here. Oh yes, I nearly forgot, we get to play with Lego. See you there!
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.