Teams form an entity – and they can have disorders. There are a couple of team disorders worth looking at. One of them is featuritis. And here is the not really serious medical guide to this disorder.
An important management tool to improve team performance is the Team Squeezer. It’s really simple: just use hierarchical power and exert pressure to make the development team hurry up. Usually the Team Squeezer backfires.
Let me introduce two characters, Bill and Chuck. To be honest, they are personae distilled from people you could meet. They are especially interesting because of their behavior: Instead of collaborating to let ideas compete they fight to get their ideas into the market. And sadly, they have good reasons to do so.
If you never have had a look at the scaled agile framework, you may want to do so. It’s has some really good concepts in it. Still with all the enthusiasm I feel like being drawn back to the good old times of software engineering. And you know why?
Scrum defines three roles: product owner, team, and scrum master. It is actually very simple. And for the team it’s great to have one person – the product owner – to deal with the really difficult stuff. That is the VVIP, the users and why the whole thing just will make money in the market.
What is it with the recent rash of manifesto’s?
Since the signing of the Agile Manifesto a plethora of other Manifesto’s have arrived on the scene. Software Craftmanship, Project Management to name but a few.
They add NO value to development, in fact it seems their sole purpose is so that the signatories can make more money.
To me, this feels like the rash of CMM’s that arrived in the 90’s. The original CMM was a useful tool for measuring the maturity of an organization. We needed one and only one. The CMM was diluted by a number of new flavours; for Hardware; for Testing; for Software resulting in a lack of clarity of objectives & direction. Finally this was consolidated into CMMI and now it has become about implementing maturity (which even sounds ridiculous).
How long will it be before the various manifestos are consolidated into another chocolate teapot? See http://www.usingenglish.com/reference/idioms/about+as+useful+as+a+chocolate+teapot.html
Much of Agile is simply about common sense. Do what is needed when it is needed!
Most of the real value of Agile methods is in how it enables us to knock the rust off old ways of working. The revelation that software development needs “people centric” is, in fact, no revelation at all.
The really big news is that developers need to engage in with the business. Oddly, this is the message that the vast majority of agilista’s fail to deliver to, failing to properly engage the business in the agile development process!
A few days ago, we had a discussion about Scrum and one person asked the question if it really isn’t possible to run effective estimation meetings with 16! persons involved. If you have an answer ready, wait. Once the problem becomes clearer, the solution is getting more interesting. It may rather be a question of maturity than of team size.
CIO magazines article on the importance of BAs to IT and CIOs is an interesting read. In particular it reinforces the difference between BAs who slavishly “flog the dead template horse” and those who are communicators and analytical thinkers. Take a look at the article here. Which type of BA are you (really)?
In Bern, the capital city of Switzerland, there lived the popular character known as Dällebach Kari (died 1931). Even so his time is almost 80 years past, he is still remembered for many things, one of which was his pointed humor. Here is one anectode in the category practical philosophy:
One night two cops came across Dällebach Kari searching for something in the light of a street lamp. “Hey, Kari, what are you searching for”, they inquired. “I lost my chewing gum over there”, Dällebach Kari replied pointing towards a dark corner on the other side of a bridge. The two policemen were a bit lost and scratching their heads they wondered, “well, why are you searching here, then?”. “Because, obviously, I have to search where there is light”, was the reply.
So: can you spot the relevance to software projects?
If you ever tried to propose an idea to somebody, you have certainly experienced a few personalities, like Joey has in this story. And after having met them Joey, for example, felt the urge to pin a picture of a cake in a sunset to his cubicle walls. For others, this is not sufficient and they have to create a lengthy comic strip.
I regularly hear the “Agile is good, process is bad” mantra from various Agile communities. In a recent meeting on development methods one contributor even declared “process doesn’t contribute to the product so we should not put any effort into processes”.
I find this mindset rather entertaining. It really does not need a genius to realize that the heart of any Agile method IS a rigid process definition. A lean, development centric process but a process all the same. For example Scrum defines ways of working (backlog, prioritization, even the frequency, duration and form of “stand up” team meetings). Deliverable’s, Roles and Responsibilities are defined too.
Ken Blanchard coined the term The Seagull Manager in his 1985 book Leadership and the One Minute Manager. Blanchard described Seagull Managers who fly in, make a lot of noise, dump on everyone, then fly out. Do agile methods help or hinder this problem?