Weinberg wisdom on agile software development
The PM Boulevard has posted
5Qs on Agile with Gerald M. Weinberg. Here are the answers to a couple of questions (the emphasis is my own):
1. Why use Agile methods?
Because they work. If they don't work in your organization, there's no reason whatsoever to use them—certainly not so you can brag about being "agile." When you do make them work, they make projects more manageable. You may or may not get quicker project completion. You may or may not save money. But you will get better customer satisfaction, and you will stay on top of your projects and be able to predict how much they will cost and how long they will take. You may or may not stay out of trouble, but if trouble comes, you'll see it coming in time to do something about it. That's what project management is all about.
2. In what environment will Agile be most successful?
The change to agile methods will be most successful in those organizations with an agile management approach to converting to agile methods. Unfortunately, I've observed a number of organizations where agile methods are introduced like a waterfall project--a huge up-front planning effort, then an attempt to convert an entire organization at one fell swoop. To be successful, the conversion has to be in small increments, with corrections made at each increment.
3. What is the future of Agile?
First we will drop the capital A. Then we will drop the term "agile" altogether. Agile methods will be successful if and when we stop seeing them as anything other than normal, sensible, professional methods of developing software.
Read the
article to find out the answers to the other questions:
4. What's the biggest challenge of implementing Agile methods?
5. Can you recommend a book, blog, podcast, website, or other information source that you find interesting or intriguing right now?
Tags:
weinberg,
agile
Links to this post
Responsibilities within a team
In a way, every person on a
team is a leader and will demonstrate leadership at different times. Among other things, every person in a
team has a responsibility to:
- Improve quality
- Instil pride of workmanship
- Increase output
- Find better ways of working and make continuous improvements
- Remove the causes of failure
- Provide training
- Help others do a better job with less effort
- Make it possible for everyone to do a better job with greater satisfaction
Tags:
deming,
team,
leadership
Links to this post
Steer based on visibility and regular feedback
Via
Agile Advice.
Ken Schwaber tells an anecdote about Scrum:
I was talking with the CIO of a large organization. He complained to me that he would run projects that would take 12 to 18 months and at the end of the project he would get something that he didn't actually want. I told him that I can deliver what he doesn't want in one month.
Tags:
scrum,
visibility,
feedback
Links to this post
Leaders use work to grow people
Via
Mike Griffiths.
Managers use people to accomplish work; leaders use work to grow people.
Leadership can not be taught, but it can be learned.
Tags:
leadership
Links to this post
Don't do Scrum without XP
I've been doing XP since 2000 and Scrum since 2004. I've never done Scrum without XP and, these days, I don't think of them separately anymore. I guess over the years they've merged into one for me and matured into my own concoction of principles and practices, still largely based on the
Manifesto, enhanced by
lean thinking, and extended with my own bag of tricks devised through tough commercial experience.
I have to agree with Jeremy Miller,
Scrum is fine but don't leave the XP practices at home. Actually, I think Scrum is great but, to be honest, I'd feel very nervous doing Scrum without the XP practices because
I care about software. In many teams, doing Scrum without the XP practices would just produce crap code more effectively. If you want to do Scrum, I strongly recommend that you do the XP practices too.
I do think Scrum's 30-day Sprint duration is too long. In my experience, I always saw
Parkinson's Law and
Student Syndrome set in during the 30 days. If you're new to
iterative development, by all means start with monthly iterations but make it a top priority to achieve
weekly iterations (as used in XP). If you're using weekly iterations but it's not possible to 'ship' working software to your production environment every week, try using Scrum's monthly cycle as a release cycle containing four 1-week iterations. Obviously it's preferable not to queue the output of iterations but the queue is manageable at 4 weeks worth of working software, and releasing monthly drums out a release rhythm and allows you to establish at least some incremental flow of valuable
marketable features to customers. This is better than releasing sporadically based on marketing dates and having to use much larger queues while delivering zero value to customers for longer periods of time.
Tags:
scrum,
extreme programming
Links to this post
Generalised. Prioritised. Committed.
Short posts with deep wisdom from Jason Yip:
Over-specialisation leads to over-sized teams. Over-specialisation means that there is no small team that has enough knowledge to accomplish any project.
Prioritise to maintain options. Every feature implemented before its time removes an option to defer that feature to protect schedule.
Customers aren't disappointed when you don't meet your commitments; they're disappointed when it means they can't meet theirs.
Tags:
generalizing specialist,
prioritization,
deferred commitment,
commitment
Links to this post
Magnetized teams
The
Wikipedia definition for magnetism is:
Every electron is, by its nature, a small magnet (see Electron magnetic dipole moment). Ordinarily, the countless electrons in a material are randomly oriented in different directions, leaving no effect on average, but in a magnet the electrons tend to face the same way, so they all pull together, thus creating a strong total magnetic force.
In an unmagnetized material the magnetic dipole moments are randomly aligned:  | In a magnetized material the magnetic dipole moments are aligned in parallel and in the same direction:  |
Imagine for a moment that every magnetic dipole moment is a person in a team. In a
magnetized team everyone shares the same vision and pulls in the same direction, working together to achieve the same goal as shown in the following image by
Mike Griffiths.
Tags:
team
Links to this post
Managing knowledge plays a part in achieving agility
Jack Vinson recently posted
10 tips on Knowledge Management strategies. You should be thinking of these if you want to achieve lasting agility (the strikethroughs and [text] are my editions):
- Manage the change
- People before technology [and process]
- Behavioural change
- Organisational culture
- Strategic alignment
KM [Agility] in the wild- Technology is an enabler [so are tools]
- Adopt
KM [agile and lean] principles - Don't stop at the first solution
- [Intrinsic] motivation
Tags:
knowledge management,
agile
Links to this post
