Agile ALM
Do you have an Agile Application Lifecycle Management plan?
Agile ALM's are good when taking waterfall centric teams on the Agile journey (ALM's are not Agile specific, arguably they are waterfall in their nature). If you are converting a waterfall team, draw up a ALM, they'll be able to relate to this very easily and quickly. I have a PowerPoint slide that has the high-level view above and then a transition smart graphic that covers each one in greater detail. Use each section to your advantage, highlighting Agile practices / benefits against each of the above.
Steve Jobs – The worlds greatest and worst product manager
Steve Jobs was the worlds greatest PM because he made products that sold, he managed to convince us to share his vision and go on a journey with him.
We could also say that Steve Jobs was also the worlds worst product manager, as his vision wasn’t always in line with what his customers would want (I count myself amongst these), he managed the masses by selling older technology at over inflated prices (Intel only joined recently, still no blu-ray, serious gfx cards only in the latest Mac’s, Apple TV 720p only, etc..) but through some of the greatest product management (marketing, style, etc...) he managed to convince people like me to part with their cash to purchase one or more of his products (even if I do use Windows 7 on my Mac Pro more than OSX Lion).
Who else could have convinced the world that they ‘needed’ a smart phone, a tablet or to pay double the price for an inferior PC? Microsoft tried for years through numerous leaders and failed, Steve jobs on the other hand reined supreme.
RIP Steve
Professional pride
For me one of the key characteristics of a good worker is that they have professional pride in what they deliver. Not a quality obsessive who keeps over engineering a piece of code to make it 'perfect', for those reading this who fall into that category perfection is subjective and often means little in valuable return with diminishing returns (a future blog post) and aren't normally working in a TDD environment.
Someone with professional pride wants to get the job done right and deliver on time with a hint of exceeding the expectations of those they report to / deliver to.
Characteristics of someone with professional pride;
- Chips in when a team member is struggling
- Doesn't like letting the team down
- Works overtime to get the job done if they fell behind
- Push's the technical edge slightly without risking the timeline or complicating the product
- Constructively helps drive the team to meet the required QA within the commitment period
- Personally feels responsible for a successful delivery
- Thrives on kudos and not only focused on money (though the persons boss should reward accordingly for a individual having professional pride)
- Willing to take on challenges outside of their expertise when asked
- Wants to help raise the teams productivity, efficiency, etc..
- Wants to demonstrate a piece of tech or an improved way to work / product enhancement that they have researched in their own time
Characteristics of someone 'lacking' professional pride;
- Doesn't care if they fail to meet a commitment
- Doesn't care if the team fails to meet its commitment as long as they have completed their work
- Fails to communicate any risks at the earliest possible point
- Doesn't want to help assist a team mate in trouble
- Makes excuses for not being able to work outside of their comfort zone when required (i.e. coding language, product domain, etc...)
- Only concerned with getting paid and doesn't care about the success of the product
- Only enjoys the glory jobs and shy's away from mucking in when required
- Doesn't care....
feel free to add any point here
There are more characteristics, but I like to time box each posting I write to a maximum of 20mins, so I'll revisit the lists above again in the near future.
Success is having good leadership
For a number of years I've heard businesses discuss the importance of strategy and what the business strategy is or should be. This is completely valid, but what is often missed out is that strategy without leadership is a complete waste of time. Who is going to take ownership of seeing that strategy through?
I'm going to give two great examples of failed strategy due to the lack of leadership, both the companies names will remain unanimous, both were at polar opposites, one a global corporate giant and the other, though a heavy weight in its own industry, was a charity. Both organisations were at different stages with defining strategy, but both stories should serve to remind you why leadership is critical.
The charity's senior management decided to ask each department, some with no representation at the senior level, to define its own strategy without any direction from the senior management. The outcome of this was obvious, long before each department attempted to define a strategy, this exercise failed. The strategy (or lack of) failed because of a number of reasons all related to leadership. There was no direction or guidance from the senior management on how each department should go about defining their strategy and how this would align with other departments. The outcome was that only a handful of departments defined anything slightly useful, and then these individual department strategies would clash with other departments views. This led to the creation of a 'fluffy' strategy, little meaning and very little value. The senior management were happy though, a fluffy strategy lacks definition and therefore direction, so affectively any individual department's agenda would be supported under the fluffy strategy.
All this strategy helped achieve was to allow further abuse my various departments by having a fluffy strategy that validated anything they wanted to do. A fluffy strategy is more dangerous than not having one.
The large corporate had a well defined strategy, the nominated leader opened the doors to the palace, sent the customary email to the whole of the business and then slammed shut not only the palace doors, but the iron coated titanium gates. Who was ensuring that the strategy was being carried out? Local heads? The do'ers in the business? Who? Sure the vision had been shared, but then the missions were left to everyone else to carry out, but where was mission control? Was the nominated leader to thinly spread to engage on a regular basis? Disinterested?
There is reason in each of the questions marks above, as no one really knew the answers. Great leaders realise that it is not enough to tell someone quickly what they want, but that they have to remain engaged until those who need to understand actually understand what you are trying to convey and achieve. Even then a good leader remains particially suspicious, and keeps engaged until the point that was conveyed has been delivered against.
Visual Retrospective Generator (beta)
As we had to delay the launch of Scrum Solutions until 11th August we didn't want our customers to think that we had forgotten about them.
While the rest of the team are busy working on iOS, Andriod and Win mobile projects, I was busy listening to my followers and by far the most popular article on my site was the article and code for generating the Visual Retrospective. At the time I had promised to write an application that will help you generate the visual retrospective.
That application is now ready (admittingly in beta, while I sort out some of the format defects).
[Download]
The application allows you to output your retrospective's in the following formats;
- HTML - Visual retrospective wall
- HTML - List style
- MediaWiki
- XML
- CSV
- PNG
The application will allow you to output to multiple formats in 1 click, useful for generating a visual retrospective as well as keeping your PM happy with a CSV formatted list
. For what all the options do read the READ ME Visual Retrospective Generator text file that's included in the package.
Quick start tip: Check HTML and check the 'Copy support files' to generate your first Visual Retrospective.
Once I (or the team, nod, nod, wink, wink) have fixed the defects there are some other features in our product backlog for this, I'll post a new blog each time its updated.
And one final thing, this tool is free and will always be free. The only time there will be any costs is for companies wanting to integrate the tool (through its API) into their solution or if a commercial company wants to remove the Scrum Solutions logo or link.
Requirements: .NET 4, Windows XP/Vista/Win 7
Missing a feature? Any negative / positive feedback? Please leave a comment
Cone of uncertainty
Above is a cone of uncertainty, this image demonstrates how larger stories come with greater risk when not broken down further.
Small stories between 1-3 pt’s shouldn’t have a grey area because for the team to know that a story is so small they should have a good grasp on what is required to deliver that story. I have placed the 5pt story on the line border of having grey matter, as though 5pt stories are of a size where the team should know whats required to complete the story, I have found in practice that this is not always the case and often 5pt stories end up being more like a 6pt’ish story
.
As the story sizes increase, so does the grey area, and the grey area is not directly relational to the ideal inner cone. Get your scrum master to keep track of estimations, the actual time taken to deliver and from this you will be able to calculate your teams multiplier for the ‘grey area’. You can then use this in your sprint planning sessions as a safety buffer.
How do you minimise the ‘grey area’? Due to the nature of large stories it is not possible to remove the grey area completely, but you can utilise methods to reduce the ‘grey’. Having well defined stories and story acceptance criteria all help reduce uncertainty around a story. Though I’d rather spend time out of a meeting, if you have a 10 pt story and your grey area multiplier suggests a 3pt buffer, but a meeting would only take 30 minutes to help add clarity to your story, do the meeting as this may reduce the 3pt buffer. Do all that you can to reduce the grey area, but accept that you will never be in a position to completely remove this grey matter.
Visions and missions
In many businesses you will often hear people talking about visions and missions
Very often I've heard people refer to both visions and missions being the same, they are not.
A vision is a long term, on the horizon, place you would like to get too, you plan your missions to achieve your vision.
How does this translate into the real world? In Agile terms you could view your vision as being the end objective for your product and your missions could be your theme's, release plans, Sprint plans, etc... (depending on how you do this within your business). For example;
Vision
My vision is that my e-commerce site has more features than another
Missions
To achieve my vision I will need to;
* Build a product search area
* Build a checkout process
* etc....
You will often find that your vision will be determined by the board / senior management (in alignment to the business strategy) and the missions will planned by the Program Managers, Release Managers, Project Managers, Product Managers, etc... and the execution of these missions by all of the 'doing' staff.
Good leaders (I'll be doing a post about leadership very soon) will form a vision that is 90% achievable and 10% very difficult to achieve, but pushing boundaries, as this will challenge the teams. Leaders, to make this work, put a bonus on the team achieving that additional 10% (depending how generous you feel, and if you run with minimal marketable feature sets (MMFS) then you could use everything below the mmfs line as your bonus targets).
To avoid confusion I wouldn't have visions as part of your project planning (unless your project is on a greater timescale than your companies vision, i.e. the company has a 3 year vision and your project is going to run for 5 years), as a project should really be a mission to help you achieve your business vision.
I specialise in all things Agile (XP, Kanban, Lean), in particular Scrum. I have a passion for taking on 'problem' projects / teams and turning them into a sucess as well as promoting automated test driven practices.








