June 4, 2009
Filed under: Agile, Business, Teams — Aldo Cauchi Savona @ 1:09 pm
I came across this article by Tobias Mayer, a Scrum Trainer and Coach where he discusses the pros and cons of using time against estimates. He describes some of the arguments people (managers and customers usually) bring up in favour of using hours as an indicator for cost. As a Scrum Master, I have come across all the arguments in Tobias’s article can be found at his site Agile Thinking here .
In this article, I will look further into estimation problems and describe empirical reasons that affect the ability of people to provide accurate estimates in relation to teams being asked to estimate in hours or worse, converting story points into hours.
When the team estimates the size or effort it takes to build a certain piece of functionality a common answer would be “about 2 days” (a guess) or “3 hours” (a relation to a past experience). However, it is non un-common for a 4 hour story to take 12 hours. The hour estimation problem does not get better with experience.
More often than not, the team is optimistic about its situation and estimates and have a tendency to measure effort of “ideal” days. However, our work gets disturbed by emails, MSN, the occasional joke, birthday cakes, and so on. Sometimes we manage to develop at lightning speed and at other times it seems like all the gods are against us having our IDE crash, issues crop up and writing a simple piece of code would drags on.
Story estimates are should also done one or two sprints ahead where all the variables are not yet known. In some cases, I have seen teams estimate their stories before they enter the sprint. In such as situation, a direct conversion into time is possible as the team should have a good understanding of what it is getting into and the degree of error would be minimal. However, the further away a story is from implementation, the harder it will be to estimate.
One can think of estimating distance as an analogy. In general, a person is more accurate when estimating the length of a finger compared to estimating the length of a room. Then again, people are better at estimating size/distance than duration [Mike Cohn, Agile Estimating & Planning].
Our capacity for estimation is also dependent on several other cognitive faculties and conditions. Representation of time is based on memory and is generally expressed as a repetition of the past. Age, culture and successess (or failures) also have a decisive importance on our capacity for estimating duration [Géry d'. Ydewalle , et al., Cognition in human motivation and learning]. When the future and context conditions are unknown, a time estimate is more of an uncertainty estimate rather than a predictive [see Richard A. Bloc, Cognitive models of psychological time and Ricardo Valerdi (MIT), Cognitive Limits of Software Cost Estimation].
A common explanation tool used in traditional project management with regards to estimation effort is the Cone of Uncertainty. It is said that the uncertainty decreases as the project progresses towards the finish and accuracy increases. This is based on the assumption that the project domain in known up-front and most variables are fixed. In a world where “change is the only constant” (Heraclitus), this is not always the case.
Agile processes place a lot of value in the ‘human condition’ and accept people for what they are, thus creating an environment where people can perform give our de-facto constraints rather than ask people to perform tasks to a certain level of accuracy when the human mind is not built for such tasks.
While accepting the fact that estimates may not be accurate, we can still use our knowledge of how cognition works to help improve story estimates. As people are better at estimating size/distance in comparison to time, rather than ask ‘when‘, it is better to ask ‘how big‘. Also, by providing context (e.g. having a direct reference to something historical such as a similar story) helps to provoke our memory to retrieve data relevant to the current story that will improve accuracy. So a better question is ‘how big is this story compared to that story’?
When it comes to estimating the cost of software, the most common pitfall is to attempt to convert story points into hours. This is, in my opinion, a big source of a problem as the estimates are in place for getting the team’s understanding of a project’s complexity. In Agile processes, there is usually a clear distinction between people who implement the project and people who sell/own the project. When managers push for a direct conversion between the estimated points into hours, they are unknowingly pushing the burden of software cost onto the team and crossing this boundary.
Another factor which we should keep in mind is that story points are a measure or abstract time, while hours, which are a measure of concrete time [Mike Cohn, Agile Estimating & Planning]. Apart from the impossibility of such a task from a physic’s and philosophical approach (abstract can be multi-dimensional and span an infinity, while concrete is one-dimensional and finite), how would one factor in the individual factors when the estimate is a team (collective) velocity?
I would argue that the role of a Manager in an Agile process is to find ways and means to bridge the gap between points and software cost. If this role is pushed on to the developers, why have a company pay a manager’s wage?
Thanks to Dave Sammut for his input in creating this article.
March 24, 2009
Filed under: Agile, Business, Enterprise, Teams — Aldo Cauchi Savona @ 10:43 am
It’s that time of the year for our annual review and appraisal session here at MC Malta. We all know how tough these sessions can be, especially when you manager walks into the office, sits down, sets his papers right (all the while looking at the papers with big red markings), looks at you with a gloomy face and says “Joe, you’re only a 5 this year and I’m afraid that’s a bit disappointing. You’re team mate, Fred, just got a 9. What shall we do?”
Luckily, most employee reviews are never so bad, but some of us might have been there.
For an Agile perspective, employee reviews and appraisals follow the same principles of Agile retrospectives where we:
- Discover and prove what works and what did not work,
- Analyse and refine our data,
- Find out how to do it better.
All that we do in Agile should work in rapid cycles, have clarity, be time-boxed, empower the employee and focus on the team rather than the individual.
Cycles
Many companies work with yearly performance and appraisals. Being THE review, it places a lot of pressure on the employee and the company. Agility is based on rapid / immediate feedback.
Agile reviews are held on a more frequent basis such as a monthly or weekly review. How can this be achieved? In Agile companies, project and management is tightly integrated with the team itself, rather than disassociated and in another department or location. Also, the team would produce enough daily information to give management a clear indication of what its performance is.
Clarity
Agile reviews are based on clarity in that the criteria for the assessment procedure upon which employees will be reviewed are made available to the employee much before the review meeting.
Time-boxed
Time-boxing is a valuable tool and applies to all areas of Agile processes. The review is based on a specific period the employee was at the company.
Empowering
Agile leadership shifts the focus from a command & control tactic to a culture of mentoring and support. After a set of action points have been identified, management would allow the employee to choose which areas to focus on, and decide on the best way to achieve the chosen goals. Management provides the guidance and supports the employee in his decisions by providing training, time or other resources to achieve the goals set.
Focus on the Team
In order to build a successful team, management should focus on the team by providing a single goal to the entire team. This idea is kept in mind during the review where Agile management shifts the focus away from individual criticism to a team-based point-of-view thus helping to promote the team’s vision. For example, if an employee is highly skilled but lacks good communication thus hindering other team members, this aspect would be highlighted.
The Retrospective Process
Discover and prove what works and what did not work
The first part of an Agile meeting is to collect the data available from various sources. The meeting would review the influence the employee had at different levels including, the Team, the Project and the Company.
In certain Agile companies, it is the team that actually leads the review rather than management. In any case, the team review should be open and in front of all team members rather than behind the closed doors of a manager’s office.
During the life time of a project, the team would generate quite an amount of data that along with process facilitator’s help, is collated into meaningful information for use by project managers and management. This information is also brought into the employee’s review.
The traditional notion of employment in the West is slowly shifting away from the traditional skills-based contact (see Economic Company by Mary Poppendieck) towards a symbiotic relationship (see River or Learning Company by Mary Poppendieck). Here the company and the employee reach an agreement on how they can help each other grow.
Analyse and Refine the data
In this part of the meeting, the data gathered is analysed. Management seem to be addicted to scores (or metrics), so in one form or another, scores will come into play. I myself had to provide scores in an Agile company I worked with. Scores are fine as long as they are used as a tool to provoke discussion rather than as a final judgement. It is important not to compare employees and that the focus of this section is to identify excellent and problem areas.
Action points and Goals
The last part of any Agile meeting is to summarise the collated data into action points. The focus here is on providing possible solutions to the analysed data. See Empowering above.
Further reading
Jeff Sutherland, one of the founders of Scrum, published a Agile review process in 2006 that was in use by a corporation for over 10 years. The process can be found here. The review template can be found here.
Mary Poppendieck, a leader in Lean development, gave a presentation at Agile 2008 on performance appraisals and bonuses. Her slides can be found here.
Other related links:
http://tech.groups.yahoo.com/group/leandevelopment/message/2604.
http://runningagile.com/tag/performance-reviews/.
http://linked2leadership.com/2009/01/05/reviewing-the-review-process/.
http://www.leanblog.org/2008/10/professor-channels-w-edwards-deming-and.html.
September 18, 2008
Filed under: Business, Enterprise — Aldo Cauchi Savona @ 12:38 pm
I had written this article in February 2008 after listening to a talk by Boris Gloger called “Scrum - A way to change enterprises” at the Agile Malta conference in February 2008 and discussed the subject with a DSDM practitioner friend of mine. The article a time in my experience with Agile where people expressed they idea that “Agile” is something for developers and not for any other aspect area of a software project or the business itself.
It is most likely that at some point in time you would have heard the words “agile” or “scrum” mentioned within the company usually when people refer to the way the software developers work. However, agility is not just about the way we do software development it should be about the way the company does business.
The Agile frameworks are based on a very simple cycle of think-act-do and implement a basic inspect and adapt approach to the way we currently do our work. What this means is that at regular intervals a group of people who are working to achieve a goal, be it a piece of software or reduce the number of open issues, discuss the way they are currently working and see what they can do to improve their current situation. Thus, Agile is about making what we do better.
Why would a company decide to adopt an Agile framework? Is it because Agile is trendy within many software development companies at the moment? Well, if a company simply made the transition to Agile for the sake of being trendy they would most likely suffer a decrease in productivity rather than an increase. After all, the transition to Agile is not quick and certainly not cheap!
Why? A company has a business goal; a vision of where it would like to be. The vision can be compared to an explorer whose goal is to explore the mountain on the horizon. This goal is assessed to be achievable. Now, what the company needs is to implement a model based on business values to reach its goal(s). Agile offers a flexible framework within which a company can reach its goals. So, a company will make the expensive transition from a traditional framework to an Agile framework because it believes that the Agile framework will help it achieve its business goals faster and more efficiently. In such a case Agile becomes the business model with which the company will achieve its goals.
For example, Toyota felt that the only way to compete in their post war environment was to reach a state where they have a minimal inventory and produce cars on demand. After around 30 years they perfected this framework and it was coined ‘Lean’. Using Lean, the company suffered minimal losses during the 70s (or 80x) fuel scare and in recent years, Toyota has surpassed General Motors in vehicle sales. Also, the Toyota Prius is an exceptional business case on how they understood market demands and product a car, from concept to production in less than a year.
Toyota managed this because agility is ingrained in the way they do business. For Toyota, Agility starts from the way they deal with their suppliers to the way they care for the end-consumer.
About two years ago, I worked with a great company that decided to opt for an Agile framework called Scrum. The first department to start using Scrum was the development department and we started the transition about 1½ years ago. The main reason why development was 1st targeted is because Scrum’s initial focus when it was conceptualised back in the early 1990s was software development and it was mainly focused on improving the collective output of teams.
This does not mean that only the development department can benefit from the Scrum framework. Many companies have adopted Scrum to handle their customer support and IT services too. At the 1st Agile Development Conference held in Malta on 19th February 2008, I met a person from an insurance company (I think it was Atlas Insurance but can’t quite remember) where they implemented Scrum principles in the way they handle claims to improve the way they work. The net result was improved productivity and reduced stress on the employees. Many other examples of successful non-development oriented can be found on the internet.
However, even if Scrum is implemented within individual departments and they each manage to improve individual department output, each department will still be an independent silo. This will prove to be a limit to the team’s output and the only way to get more productivity is to apply the same principles of Scrum that applied to a team to departments. The end result is that the business model will change, where, rather than have vertical individual departments (i.e. a traditional organisation hierarchy), you implement horizontal inter-department teams that strive to improve productivity on a ‘product line’. These teams will involve members from all departments relevant to the product, for example, members from the Sales, Marketing, Support and Development departments.
By having a member of each department that will have an affect on the product in one team, important decisions that can impact the company’s direction can be taken quickly. Also, the wishes of each department will be represented within a product line from the start. With this approach, inter-department commitment to a product will be stronger and more united. One major corporation that has gone through this restructuring programme is BT who gave a keynote presentation about their process at the November 2008 Scrum Gathering Conference in London (Scrum@BT).
A founder of a billion dollar company expressed the power of unity as “If you could get all the people in the organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.”
Aldo Cauchi Savona – Feb 2008
