The certifying committe just accepted my CSP application.
I like where scrum certification is going. Hands on experience should be a requirement.
The certifying committe just accepted my CSP application.
I like where scrum certification is going. Hands on experience should be a requirement.
I have managed Oxygen’s Software Development Team for five years.
Each year, our aspirations grow to encompass widening arcs of project, team, and company.
It all seems planned but it’s a pattern of intended and emergent strategies. Agility embraced from the bottom up with the support of our CTO, Steve Morgan.
Beautiful.
Year | Focus | Theme |
---|---|---|
2003 | Projects | Build mission critical software. |
2004 | Team | Adopt Scrum and XP. Become a real team. |
2005 | Advocate by doing. Remove obstacles. Perform. | |
2006 | Company | Earn trust with the CEO. Contribute to innovation. |
2007 | Earn trust with the COO. Contribute to revenue. | |
2008 | Consumers | Software as profit center!? |
I’m a moderate in the agility vs. discipline debate.
Scrum/XP has worked for my team. Four years in, we deliver better adapted solutions with higher code quality.
What I love about Agile is that it acknowledges what’s hard and treasures what’s valuable. There is inherent complexity in modeling partially understood and fluid problems. There is deep potential in talented people rallying to achieve a goal.
However, Agile is not the only path to valuable software. As Stephen McConnell and Barry Boehm say, it’s all a matter of the appropriate tools for the appropriate context. Different levels of planning, description and formality have their place.
The only way to know whether a practice works for your team is to learn it (seek mentors), apply it with discipline, and track your performance over an extended period of time.
The infuriating thing is many shops don’t think deeply about what they do: “The Demise of the Waterfall Model Is Imminent” and Other Urban Myths
The value of any practice is really doing it.
I want to collect together all the terms that describe activities at the start of software projects.
The fuzzy front end
Big design up front
Any additions? Please…
Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results. — Ken Schwaber Scrum and NonScrum
My team embraces retrospectives. Every two weeks we list what we’ve done well and what we didn’t. We choose one or two things to do differently in the next Sprint. We revisit those commitments over time to see what progress we’ve made.
My team exists in a larger company.
In Waltzing With Bears, the one irrefutable reason to not do risk management is when no one else is doing it. If you are the only one presenting costs and possible negative outcomes management will assume your projects are troubled and you are a negative thinker. They’ll fund proposals that by comparison look cheap, safe and promise outstanding success.
I don’t exist in that extreme situation. But my team’s willingness to acknowledge mistakes is sometimes taken for negativity. Our willingness to admit the possibility of failure sometimes provides support to skeptics. Our willingness to question assumptions is sometimes seen as stone throwing.
Leading Change
In order to build something new we straddle two realms. In one we cultivate our aspirations and in the other we struggle to attain them.
At times we need to set aside our skepticism to see the world as it should be and people as we hope they are. Other times, we need to see how far we are from where we aspire to be, dig our feet into the soft earth and push.
Jeff Sutherland has a simple exercise for spurring organizational change
You’ve just planned a Scrum.
The Hair Shirt
There is a difference between justifying one’s mistakes and reflecting on past performance in order to improve. There is also a difference between acknowledging one’s fallibility and dwelling on it.
We developers are crafts people not monks. Our job is not righteous contemplation — it is thoughtful and rightful action.
So as reflective developers, we do not wear a hair shirt. Our goal is not to dwell on our own or other’s failings.
We are idealists.
We embrace grand visions, ambiguity, contradiction and change. We believe good people deliver the best results in environments of trust and honesty.
.. And we are pragmatists.
We believe believing doesn’t in itself make it so: success requires discipline, determination, and ingenious problem solving.
And as we embrace both the outcome to which we aspire and the given circumstances that surround us we will acknowledge mistakes. We will shine a bright light on obstacles in our path. With humility and tenacity we will challenge ourselves, our teams, and our companies to do better.