Published in Halliburton Lifecyle for Software News - Volume 4 November 2012
Did you take piano lessons as a kid? Most of that instruction centers on playing all the right notes, at the right time, using the right fingers. It focuses on the mechanics, but is that enough? Is that why famous musicians are famous? Do people swarm to a Springsteen concert because he plays (and sings) all the right notes? Vladimir Horowitz played the Brahms 2nd Piano Concerto literally thousands of times. Did he continue to pack concert halls because he used the right fingers? Musicians gain fame not because of their mechanics, but because of how they use those mechanics to "make music".
But how do you define "making music"? Isn't that very subjective? "Making music" to me is Mozart or Beethoven. It is Brahms, Strauss and Puccini; Mahler, Stravinsky and even a little Bartok. The Beastie Boys? Just unorganized noise to me, though in some circles I'm in the minority. "Making music" is intangible, and as with many things in life, the intangible outweighs the tangible. We too often focus on the mechanics because they are easy to define and measure, not because they ensure the results we seek.
Now consider Scrum teams who "make music" in the form of working software. Are they successful because they work in iterations? Do they excel because they hold daily standups or observe all of Scrum's ceremonies? No. These are the tangible, easy to measure mechanics of Scrum. Our real and intangible goal is in how Scrum teams work together; how they collaborate and innovate to achieve high quality solutions to the business issues of the day. Just as properly fingering the G-Major scale does not ensure my ability to "make music", grasp of the Scrum mechanics does not ensure a team's ability to produce valuable working software.
So what does? The short answer of course is nothing. We can only look to things trending toward that goal and keep adapting to improve. Take any ensemble of musicians. What makes them successful? First, each member has transcended the mechanics to making music in their own right. Second they have a shared purpose and common goals in making music together. Third they have achieved a level of collaboration through mutual agreements of how to play together. Fourth they have the freedom to actively learn from experiments to continuously improve. All of these are intangible. Each group learns their own unique balance to achieve their own end goal of "making music".
This is exactly what we need for Scrum teams as well. We need teams that are fully cross functional, each member having a high technical competence. We need teams with a shared purpose and common goals. We need teams free to make working agreements around how they will proceed. And we need teams continuously trying new things in order to learn and improve. Will this ensure Scrum teams "make music"? No. But it is how teams learn to transcend the mechanics and strike their own right balance in creating valuable working software. It is our best hope of getting the quality solutions our business partners need.
Software development is about answering questions. Answer the right ones and you have a viable, useful, well-thought of product. Answer the wrong ones... well, we've all see that software at work. Based on my experience working with software teams, here is the series of questions I believe keep us on the path to successful product launches.
The big up front question of course is What is the business problem we need to solve? Ensuring a good answer to this question is our first critical step.Read more...
Does that sound like your Scrum team? Is the sprint goal that big of deal? In short yes, the sprint goal is a VERY BIG deal. Here's why. A team that regularly misses its sprint goal is thought of as a team that:
- can't plan its work
- does not really know its own capacity
- does not estimate stories and/or tasks very well
- does not have sufficient competence to do the work they have been asked to do
- is not trustworthy -- they don't do what they said they will do Read more...
Agile 2011 was by far my best experience yet with the Agile Alliance conference. Two well coordinated keynotes served as bookends setting the tone that agility is about people and how they interact. First Barbara Fredrickson shared her work on the theory of Positive Emotions and the effect creating a positive mindset has on discovering new traits and skills. Then as the final event of the conference, the irrepressible Linda Rising closed out the conference sharing her view that an Agile Mindset makes us resilient to challenge, helping us stay focused on the path to mastery.Read more...
Think true collaboration for distributed teams in not possible -- think again. Here is a stunning example of combining shared vision, barely sufficient control, and technology to achieve fearless results.
Watch Eric Whitacre's presentation at TED2011.
- What's In Your Agile Leadership Vocabulary?
- Three Failures to Avoid in Agile Transitions
- Agile2011 Business and Project Management Stage
- Agile Mind Shifts
- Where is YOUR Evolution Headed?
- In Hindsight…
- Agile2010 Reflections
- Higher Incentives Lead to Poorer Performance
- Stairway to Agility
- The Elusive Agile Enterprise
- The Practices Isn't What's Hard
- Not Suitable for Agile?
- Agile2010 Experience
- The Power of Self-Organizing Teams
- Everything Super Talkcast
- Control is Not Evil
- That’s Not My Problem – and That’s OK
- What's a Manager to Do?
- Brian Marick’s Seven Years Later: What the Agile Manifesto Left Out
- Pollyanna Pixton’s Collaborative Leadership: A Secret to Agile Success
- Agility: What’s In It for Me?
- You Want That When?
- The Art of Burndown
- Agility: Its Advanced Citizenship
- Individuals and Interactions
- What is Wrong with Waterfall?
- Succeeding With Agile: A Guide To Transitioning
- The Role of Leadership in Software Development
- Requirements Truths