June 22, 2009
Filed under: Agile, Quality, Teams, Test-Driven Development — @ 10:12 am
During the transition phase from a tradition process to an Agile process, the word “Test” and it related activities, in my experience, always seemed to draw a heated debated between the developers and the testers in a company. Using an Agile framework, the test activities are drawn forward in time to the point where testing starts right from the beginning of software production. There is also the concept of “One Team”, where testers and developers are all “team members” with specialist roles, thus reducing the unpleasant “us and them” culture that was cultivated over the past years.
Test activities are drawn forward by bringing people with test and quality assurance knowledge into the scoping and estimation meetings and participate in the team all throughout the project. The main reason is that we are not only testing what is being produced, but the entire process (some of which we always do without noticing). We test the nature of the functionality, explore the customer and manager’s pre-conceptions, verify domain knowledge, check the validity of the design concepts, what is being produced and what has been produced in the past.
This topic has been discussed quite extensively online and here are some links to blogs, articles and discussions on the subject:
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.
December 14, 2008
Filed under: Agile, Events, Teams — Aldo Cauchi Savona @ 11:05 pm
This post is an overview of my talk at the December 2008 AgileMalta conference. It is slightly oversimplified, but there is only a certain amount one can say in a blog post 
I hope that this post will help you get more value from the talk slides. My main interest in Agile lies in the area of Process Facilitation and Team building. It is my opinion that the greatest investment a company can make, is to improve the quality of its workforce and in the creation of one or more Teams.
The presentation is based on the following observation: A team is inherently dysfunctional.
It is common knowledge that the greatest ‘resource’ of a company is its workforce. Also, the quality of these ‘resources’ has a major role in determining the outcome of a company’s projects. From a traditional approach, the idea of quality lies in the skill level and the experience the ‘resource’ has. The focus is mainly technical. The person is viewed as a ‘resource’, a replaceable part, a concept that stems from the idea of specialisation in the manufacturing industry (see Implementing Lean Software Development: From Concept to Cash, Mary & Tom Poppendieck, 2006).
The focus of attention is also on the individual. Most of our progress (from school to work) is measured on our personal ability. We have personal reviews with our managers who give us personal targets to reach in order to attain a new level in our career or change our pay-scale.
The talk also delves into a bit of psychology with regards to the evolution of the Ego… Over time (past couple of centuries) people developed an Ego and psychologists say that it has now reached its peak. By ego I refer to the psychological notion which allows us to say “I” or have a concept of “self” (see The Archetypes and the Collective Unconscious (2nd. ed), C.G. Jung, 2002).
As such we can say that, due to our individuality, we are naturally dysfunctional within a team. Companies further promote dysfunction by focusing on the individual.
In the presentation I also make a common distinction used in Agile between a Group and a Team. A Group is the most common setup within companies. Each person in the group has a particular area of expertise, role and responsibility. While working on the same project they are working towards different targets (namely, the ones set by management).
In contrast, a Team happens when each person in the team is moving in one direction. From an external point-of-view, the team is a single entity with one goal.
In team-building exercises, attendees are often shown an image of synchronised rowing. There is also a common cheesy poster I saw in a three companies I worked for with such a photo and the title “Teamwork”. However, when we set individual targets, each person is offsetting the rhythm of the group hindering the speed at which they reach their goals (see slide 10 in presentation). It is called synchronised rowing for one main purpose: each member in the boat rows to the same rhythm. The more synchronised the team is, the faster they reach their goal.
Should a company decide that they would like to have a team and not a group, it first has to realise that it is dealing with people that are more complex than a fixed ‘resource’. Also, since individual ‘treatment’ is not the solution, the next step to resolving dysfunction, is to decide on a single goal for the team. The decision is made together with the team and not for the team.
While the whole company is involved in creating the team, the emphasis is now on the team and it has to find a way to reach this goal as fast as possible. The team has the help of management or in Agile, the process facilitator, who helps them find the motivation required to reach their goal.
This is only the starting point. The common pattern that emerges is that individual traits that hinder development speed are brought to the surface. Other issues, technical or otherwise, that before were easily covered up are also exposed. The first reaction to this situation is usually a retreat to the safety of the past behaviour. This is where most teams fail. You will need to courage and persistence to surpass the difficulties that arise if you truly wish to reap the benefits of a team.
Click here to download the talk slides “Building a Successful Team”.
October 1, 2008
Filed under: Agile, Teams — Aldo Cauchi Savona @ 1:42 pm
Earlier this week, I heard a comment by someone I was speaking to that they do not like Agile methods as they proclaim that the developers should not product any documentation or else, that there is no need for any planning. This was not the first time I heard this comment. One person exclaimed that when he worked in a company that used Lean practices, bad quality products were delivered thanks to the Lean practices they used!
Apparently, the people they worked with interpreted reduced documentation and planning for no documentation or planning. This gives rise to the view that Agile = Lack of Discipline = Bad Quality Products = Bad Process.
Anyone who has decided to dig a bit deeper into Agile and their theory would know that they are founded on two fundamental principles: Discipline and Quality. A great example where adequate documentation and quality driven development was used is the Boeing 777 project. Their aeroplane was ready for in-flight testing after 2 years of development, 3 years ahead of the norm.
If at the moment your team is not producing any form of documentation, or have a poor development development process, then when transitioning to Agile, you will most likely have to produce more documentation and do more planning than you currently do. When Agile practitioners talk about streamlining your documentation, they mean reducing the amount of documentation an existing cumbersome process might require. Again using Boeing as an example, the 777’s electronics specification document was over 2500 pages. When Boeing increased the collaboration with their provides, they could reduce their specification. The end result was that the 787 electronics specification document was reduced to 20 pages.
Agile methods ask all committed people to be more involved in the project, and to always act in the best interest of the project. This requires great discipline and dedication with the end result being a high quality product!
See: http://leadinganswers.typepad.com/leading_answers/leadership/;
Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck.