Tobias Mayer earlier today tweeted:
In an agile environment there is no such thing as “scope creep”. There are only better ideas.
Amen, amen, amen.
He hasn’t expanded on that tweet in a blog post (afaik); but really what more is there to be said? I suppose saying it gives those who don’t know what it means the opportunity to ask “what does that mean?” which could then be the subject of a blog post. But this is just words. That tweet expresses such an important idea.
We’re working with a slightly-distributed team. So after we do our standup, I often take a picture of the physical wall to share with the remote stakeholders. For this, I use the panorama mode of my phone.
When team members are willing to have some fun together–as illustrated by this image–I think you’re on the right track to a solidly-performing team.
One of the other developers was wandering by, and was heard to mutter “I wish I had a wall.”
I came across a posting on quantifiedself.com that I thought would be very interesting to those who think about agile principles. In an eight-minute talk with about seven minutes of Q&A, Michael Cohn describes his own experiments with tracking personal commitment and progress.
If you’re like me, when you listen to his talk, you’ll hear “planning meeting,” “commitment,” “daily standup” and “review.” He also talks about the value each of these things has in keeping him on track. I’m not going to do a detailed analysis here, just a recommendation that you might find these an interesting 15 minutes.
Cohn is talking at a personal level, but the things he says make a lot of sense applied to teams, as well.
The talk was just posted today, April 17, on quantified self. It hasn’t generated any comments there yet. If you like what you hear there, please leave them some comments … and if you want to tie your thoughts more closely to agile principles, I’d love to hear from you here as well!
I’ve written a post titled “Lowering Risk Using Agile and Lean Methodologies” for the blog at Pathfinder Software. Here, I’ll post a summary, and invite you to link on over to Pathfinder’s blog for the full version. Leave a comment in either place.
I’m interested in three kinds of risk that are mitigated by using agile and lean processes:
- building the wrong features or the wrong design (“UX”)
- changing market conditions
- the unknown
Even the best market research is more theoretical than the empirical test of building a small product and releasing it to actual users. This is true of features and of a chosen design (interaction design or visual design). It’s even true of your application architecture or production environment.
By building in small iterations that are individually complete, your ability to react to changing market conditions is enhanced.
Open communication in an accessible way, as suggested by agile principles, leverages the knowledge of the whole team to anticipate and solve problems however they arise.
The topic was suggested to me by folks at Pathfinder, who also provided some editing. So I invite you to read the entire post at the Pathfinder Software blog.
Read about this in a discussion on LinkedIn’s Agile CMMI group.
Nils Malotaux describes Five Processes that businesses use: the official one, the one we think we use, the one we idealize, the one that would be best for us, and the one that someone or something else (vendor, software …) imposes on us.
As coaches, we think we’re bringing the target process, but we might actually be bringing a perceived process . . . and everyone is subject to the process that is imposed by management, or vendor or other circumstances.
I don’t need to run on at length about it, read Nil’s entry. What do you think? Add a comment (here or there).
I really like the ideas expressed by Tobias Mayer in his post “How to Hire an Agile Consultant.” I recommend you go read his post.
I found Tobias via the comments on this anonymous “editorial”. That happens to be a post with some good ideas and concerns as well, but I have to fall in with the commenters who take it to task for its anonymity, in spite of using the personal pronouns “I” and “me” consistently throughout. Good ideas, but no-one to whom one can give credit.
I haven’t yet directly experienced the coach = scrummaster situation yet, but I can easily see how it will happen as more and more companies look for help in “doing agile.” And more and more companies spring up to offer these services.
There is some great stuff on Jiles van Gurp’s blog. Here are a few of my favorite thoughts from “Scrum: Agile Madness”
- “…you can’t substitute experience with process and that is exactly what agile followers end up doing. Take away the experienced people and you have a lot of people executing the rituals of scrum, kanban, or whatever without really understanding what they are doing.”
- “…often scrum is introduced to fix what is already a dysfunctional organization.”
- “Actually, if all of the above is true [referring to four assumptions about happy and productive teams], you will have little need for process. If that isn’t the case, no amount of process is going to fix things magically.”
- “[ironically:] A two day pep talk about scrum is apparently all the training you need to become a product manager or scrum master.”
- “[T]here are a lot of inexperienced people who get promoted to be a product owner or worse start their first or second job being one. Likewise, the scrum master role is not considered a job very high on the corporate ladder either.”
- “Choosing and tuning the way in which you work is more important than having everybody mindlessly follow the same process.”
These quotations of course are all presented here without the context van Gurp provides. I strongly recommend you read the whole post: http://www.jillesvangurp.com/2011/12/03/scrum-agile-madness/ . Thank you, Jilles, for your blog!