Search

How Not to be Agile – 2. The Business Case

Is Agile Everything?‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!The benefits of adopting the Agile methodology are well documented everywhere.  What I intend to do over these series of articles is to share with you the misinterpretations, omissions and mistakes that people make. This significantly reduces the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Agile Transformation is not an easy task! Though the ‘mechanics’ behind the Agile frameworks are relatively straightforward to implement, people have trained adequately. However, the root cause of all the troubles that I met is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.What is the Business Case?Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level,a project plan with all the ‘who will do what and when’, factoring in known team member holidays etc.  By this means, they hoped to establish the probable costs of the development with a high degree of accuracy.  However, I have never seen the expected business benefits undergo such a rigorous analysis.Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.What is an Agile Business Case?“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:Develop the product from ‘scratch’ – usually the most expensive optionUse an existing product as a ’base’ and modify/configure it – the next most expensive optionOutsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take.  I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development, development continues.”What is Agile Business Case Lifecycle?Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development.  Indeed, I use a set of development ‘document’ templates, which includes making a business case for Agile, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.Post Product Backlog CreationThe Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 4 to 5 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.At the End of Development TimeboxesA Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders.  Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary.  Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible.  However, a view can be taken on the new cost-benefit analysis as to whether to continue development.Remember:‘Fail Fast’Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.Case Study 1:Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system.  The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.The ‘Vision’ was clear:“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.That and the 6-month deadline led the team to cut corners on the preparation.  Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.After 2 months of development, the team released the first prototype to the client company to get feedback.  The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months.  It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.Lessons:1) The apparent lack of time always drives people to ‘cut corners’, especially in the preparation.  How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint?  In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.As a consequence, the team produced a less than satisfactory first prototype.2) Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.3) The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.4) On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’.  If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.Case Study 2:I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.The project ‘Vision’ was to automate many business processes that were currently being done manually.  When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything.  I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.I decided to sit in on one of these workshops to see what was happening.A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives.  They discussed their answers to the questions which mostly were preceded by ‘It depends’.  I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’.  I then asked the stupid question ‘What is a prototyper?’.  The obvious answer – someone who prototypes!  It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story.  In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about.  The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable.  As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case.  For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.LessonsDespite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.ConclusionThese 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.
Rated 4.0/5 based on 0 customer reviews

How Not to be Agile – 2. The Business Case

161
How Not to be Agile – 2. The Business Case

Is Agile Everything?

‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!

The benefits of adopting the Agile methodology are well documented everywhere.  What I intend to do over these series of articles is to share with you the misinterpretations, omissions and mistakes that people make. This significantly reduces the potential benefits when an organisation, or part of it, embark on an Agile Transformation.

Agile Transformation is not an easy task! Though the ‘mechanics’ behind the Agile frameworks are relatively straightforward to implement, people have trained adequately. 

However, the root cause of all the troubles that I met is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.

Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.


This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.
I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.

What is the Business Case?
Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.

These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level,a project plan with all the ‘who will do what and when’, factoring in known team member holidays etc.  By this means, they hoped to establish the probable costs of the development with a high degree of accuracy.  However, I have never seen the expected business benefits undergo such a rigorous analysis.

Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.

This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.

What is an Agile Business Case?

“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:

  • Develop the product from ‘scratch’ – usually the most expensive option
  • Use an existing product as a ’base’ and modify/configure it – the next most expensive option
  • Outsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.
  • From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take.  I will discuss Agile Roles in a later article.
  • There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.
  • If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development, development continues.”

What is Agile Business Case Lifecycle?

Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development.  Indeed, I use a set of development ‘document’ templates, which includes making a business case for Agile, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.

Post Product Backlog Creation

The Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.

These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.

The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.

The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 4 to 5 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.

At the End of Development Timeboxes

A Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders.  Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!

It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary.  Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible.  However, a view can be taken on the new cost-benefit analysis as to whether to continue development.

Remember:

‘Fail Fast’
Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.

Case Study 1:

Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system.  The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.

The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.

The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.

The ‘Vision’ was clear:

“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”

There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.

Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!

The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.

That and the 6-month deadline led the team to cut corners on the preparation.  Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.

The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.

The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.

After 2 months of development, the team released the first prototype to the client company to get feedback.  The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.

It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.

I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months.  It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.

The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.

We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.

The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.

During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.

Lessons:

1) The apparent lack of time always drives people to ‘cut corners’, especially in the preparation.  How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint?  In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.

As a consequence, the team produced a less than satisfactory first prototype.

2) Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.

3) The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.

4) On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’.  If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.

Case Study 2:

I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.

The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.

The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.

However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.

The project ‘Vision’ was to automate many business processes that were currently being done manually.  When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything.  I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.

The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.

I decided to sit in on one of these workshops to see what was happening.

A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives.  They discussed their answers to the questions which mostly were preceded by ‘It depends’.  I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’.  I then asked the stupid question ‘What is a prototyper?’.  The obvious answer – someone who prototypes!  It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.

I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story.  In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.

This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about.  The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable.  As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.

Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case.  For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.

To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.

Lessons

Despite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.

When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.

Conclusion

These 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.

Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.

I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.

Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

When Can You Expect Your Newly Formed Team To Perform?

I can visualize the curious facial expression of the readers out there especially if the reader is a Team lead or Manager or Delivery Head. Jokes apart! It’s a quite common scenario whenever a new chunk of work comes to an IT-Farm. A team is formed which starts focusing towards project execution. Once a team is having visibility of the requirement, a ballpark estimate is given to the client. Looks like the team is all set to perform right from outside? Hence the leadership team (inclusive of the Team lead, managers, delivery head etc.) start expecting output. Thus, unknowingly an unhealthy pressure gets built up on the team. Hold on for a second. Aren’t we expecting that with an introvert mindset? Let’s have a look at the ground reality and consider the below model. A team when formed passes through certain stages. We can consider it as a “Tree life cycle”. Whenever we plant a seed it requires extra care and nourishment. After some days of watering and care sprouts starts coming out followed by which, with time, it becomes strong enough and gets converted to a tree.Similarly, a new team when developed passes through the below 5 important stages- 1. Forming2. Storming3. Norming4. Performing5. Adjourning Let’s talk about different stages of team productivity in details:1st Stage: Forming A team enters the forming stage when it is newly formed. Members of the team meet each other for the first time. There is a minimal visibility around the roles and responsibilities of an individual within the team. Hence members are in an “observing mode”, they observe other members of the team to get the feel around the person and how they can contribute together towards the project goal. Team members tend to behave independently since they do not know each other well enough to unconditionally trust one another. Team leader plays a crucial role in this phase. They should define Project goal and should ensure an individual is having clear visibility around his/her roles and responsibilities. 2nd Stage: StormingPost forming stage, a team enters the storming stage where there are high differences among the members due to less acceptance among the individuals. Members think more from an introvert mindset and from an individual perspective. Productivity from the team member is least, members collide more with each other. In this stage, the team leader should first continuously keep track of the work and resolve conflicts. Exhaustive presence and input are required from the leader to ensure that the team is running on the constructive track. 3rd Stage: NormingPost Storming phase, the team enters the norming phase wherein there is a high acceptance around the decision and differences between the member of the team. The team becomes more mature and there is a high collaboration among the members of the team. They work more as a team rather than an individual contributor. There is a shift from an introvert to extrovert mindset among individuals. The team members start building trust towards other members and actively seek each other out for assistance and input. We can call this phase Pre-Performing phase. The productivity of the team is high compared to the previous two stages. The team leader may not be involved in decision making and problem-solving anymore, as the team is working better together and are holding themselves accountable for the delivery. However, on a need basis, the team leader can pitch in and provide direction to the team. 4th Stage: PerformingOnce a team exits the norming stage, it enters the performing stage. Here the focus is more towards achieving the project goal as a group. Here throughput from team members is at its peak. There is a high trust factor, collaboration, and proactiveness among the members of the team. Hence the team takes quick decisions and solves their problems quickly. Thus, there is a timely delivery from the team. In this stage, a team leader is not involved in decision making and problem-solving. From the performing stage, it is possible to revert to the Storming stage if a member starts working individually and is not a good team player. Hence the team leader keeps a watch to ensure that this stage doesn’t change back to storming stage. 5th Stage: AdjourningA team enters this stage when the assignment gets completed and the team can be dissolved. The entire team celebrates the success with the help of different activities ( For eg: Team party ). The team leader plays a crucial role in this phase. The leader should ensure that the members are appreciated for their valuable contribution. Here is how the performance of the team would look like-The above model is known as “Tuckman Model of team formation”.Bringing it all together“A general thought on how often being a Team leader we think of it and accordingly expect productivity from the team?” Let’s re-analyze the current stage of our newly formed team and help them achieve the “Performing” stage by working constructively along with the members, rather than creating an unhealthy pressure of delivering irrespective of the current stage of the team. Please share your thoughts in the comment section, we can connect on LinkedIn and talk more. If you enjoyed this post, spread it to your connections on LinkedIn or other channels. Thank you!
Rated 4.0/5 based on 2 customer reviews
When Can You Expect Your Newly Formed Team To Perf...

I can visualize the curious facial expression of t... Read More

12 Common Mistakes Of The Scrum Master And The Remedies 

Today, companies are becoming a part of the massive technological leapfrogging through some of the popular Agile methodologies. When we talk about Agile, people think of “Scrum” naturally. Scrum is the most widely used framework among the popular organizations. These organizations leverage Agile and Scrum methods for a disciplined project management practice, as Agile encourages continual feedback, iterative development, rapid and high-quality delivery and iterative development.                                         “Life of the Scrum Master is full of challenges, Scrum problems, and Scrum pitfalls.” According to the “11th Annual State of Agile Report” by Version One, the following figure states the top reasons for adopting Agile and Scrum methodologies in organizations. The concept is simple but difficult to implement. Being a Scrum Master can be a tough task, if unaware of the Scrum Master’s skills. Here are the most common mistakes of the Scrum Master and the solutions while implementing a Scrum framework: Look out for these 10 common #scrum mistakes with some simple tips: https://t.co/asOR8ZVj00 #agile #lean #scrummaster #devops pic.twitter.com/WUxQHtKhW5 — TO THE NEW (@TOTHENEW) 29 November 2017   1.Scrum Master acting as a Project Manager- In the Agile methodology, companies follow the “Daily Scrums”. Before starting the day’s work, teams gather around the board to discuss the current and the preceding days’ tasks. Usually, team members report on ‘what they did yesterday’, and wait for the Scrum Master’s reply on ‘which task to do today’, instead of self-organizing within the team.   This is where the Scrum Master makes a mistake. He is acting as a Manager, not as a Scrum Master. A Scrum Master should ideally make team members ask ‘what should be finished next?’      2.Scrum Master making decisions for the Team-     In most of the organizations, Scrum Masters are recruited by practical experience (generally senior developers and the project leads are given priority) and by personality in terms of communication skills and the sound mind to carry out decisions to keep the project processes on track. Due to this, team members rely on the Scrum Master for each and every decision, which is totally wrong.  Most of the times, teams consist of a variety of different personalities and letting them express their opinions can help to deliver the best. Avoid dictatorship, as it affects the team spirit, stifles progress and results in a lack of communication among the team members. This is one of the common Scrum pitfalls a Scrum Master typically faces during work.   3.Scrum Master holding sole responsibility for the delivery-   This is the common Scrum problem usually found in traditional companies, that have recently entered in the world of Agile development. In traditional companies, people were so far following the leadership style viz. ‘Command-and-control’, in which a single person used to be accountable for all the project tasks, making management impediments-free, simple, and more comforting.  Normally, Scrum Master ensures that the developers are inclined to all the project requirements. But when it comes to the responsibility of the Scrum Master to deliver the product, he/she just concentrates on the product delivery, ignoring the quality. To avoid this, stop planning projects individually. Planning is collectively done by the team members. It needs each and every team member to adhere to the commitments, to understand the target and the way to achieve that.   4.Scrum Master acting as a mediator between the Team and the Product Owner-   Suppose the team has finished with the daily Scrum and started to construct a functionality which was recently planned for the meeting. But the team is facing some difficulties and needs to discuss with the Product Owner to get an information. At this point, the Scrum Master communicates with the Product Owner to remove communication barriers and furnishes the needs of the team members. After asking the relevant queries to the Product Owner, the Scrum Master relays the same to the team.     In this way, Scrum Master acts as a mediator between the team members and the Product Owner and forms a Scrum solution to overcome communication impediments.   5. Not conducting Retrospectives after every Sprint- One of the principles from the Agile Manifesto states that- “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Sprint Retrospective is often considered as an add-on, and implemented only in free time. Agile is all about the adjustments, fine-tuning and versatility. It is really very difficult to fine tune if you seek for the adjustments every time. 6. Not removing obstacles at an initial stage- One of the main roles of the Scrum Master is to remove the impediments. The daily stand-ups is the best way to communicate the obstacles to get the task done. But in case these barriers (more correctly, the issues or constraints) are not escalated by the team members, Scrum Master will fail to remove them. Scrum Master should remind the team at the very beginning to present the potential blockades which might delay their work.     So, at the end, you can have several SMs for a team if your combination allows to get the team focused on delivering value and not wasting time on who is the Scrum Master that can help them on removing impediments or facilitating events. — Israel López (@israelagile) 27 November 2017     7. Less/ No daily stand-ups-   The daily scrum is pivotal from several aspects. It allows open communication (face-to-face), collaboration, yields visibility and transparency into the project. So, for every team member, attendance should be mandatory. During meeting, each team member should stick to the following 3 questions-  What did I accomplish yesterday? What will I work on today? What impediments are blocking me in achieving the project goals? It should, however, be noted that the teams do not have to restrict themselves to the above three questions. As per the tenets presented in the latest Scrum guide, discussion-based stand-ups are equally effective and provide insights into the latest happenings in the Scrum team.   Scrum Master Daily stand-ups https://t.co/vlORxTcJoV — Kevin Ackerman (@ackwdw123) 15 June 2017   8. Not strictly adhering to the Agile Manifesto principles- Try to keep Agile startups uncomplicated. According to Agile Manifesto- Agile gives higher value on  ‘individuals and interactions than on processes and tools’. So, Agile projects can be successful without the use of the tools. You can use stickers on the wall, spreadsheets, and manual burndown charts to keep the process simple.   12 #Principles of the Agile #Manifesto by the @AgileAlliance People matters. We are in the ages of uncertainty at work. We need our minds to boost the best of us and businesses #ProjectManagement #teamwork #SustainableDevelopment pic.twitter.com/4yFAOitEYC — Anca Fajardo (@KathiFajardo) 20 January 2018   9. Wrongly assuming an easy transition to Agile- Agile transformation takes time to set up in the organization. It always starts with mess-ups. Transformation includes dealing with the existing corporate and cultural problems like- poor communication, lack of accountability, skeptics, time management, etc. Effective Agile transformation can be a total cultural change. Be patient and ready to embrace the cultural changes. A company's transition to an Agile environment is a welcome and positive experience. But when reality sets in, some resist the change, particularly those in management. https://t.co/kxpyWqBcUB — Joe Little (@jhlittle) 21 January 2018   10. An ill-formed/non-prioritized product backlog- The most common reason behind Sprint failure is a product backlog with status “not ready”. It is also a cause for delivering low value. Making a backlog ready before the ‘next sprint’ is good. Do not let the team run out of the tasks and keep in mind that every task should be prioritized by the Product Owner.Always heed the point that being a Product Owner or a Scrum Master can be time consuming.So set the goals and provide the necessary training on product backlog to the team members.  What's in a Product Backlog? The most critical part of any Scrum project is a well-defined product backlog. How do we effectively define an efficient and productive backlog?https://t.co/QqMyGe9MBm — Dan Tousignant (@ScrumDan) 19 January 2018   11. Not handing over the ownership of daily scrums to the team-  Sometimes, Scrum team keeps some of the product backlog items undone. This results in spilling over of the undone tasks and simply shifting to the next sprint. This happens when a team fails to finish the high-priority tasks. However, Scrum Master and the team should not take it lightly. When they do this, Sprint planning become meaningless. Therefore it is mandatory on the part of a Scrum Master to support his/her team in planning of its next sprint so that they can finish everything on time. Equally essential is to make them feel accountable if they do meet the targets and the stipulated deadlines.   Do Scrum Teams Meet Too Much? One of the most frequent criticisms I hear of Scrum when teaching Certified Scrum Master courses is “Scrum teams have too many meetings.” With daily scrums, sprint planning meetings, sprint reviews, retrospectives and https://t.co/O9t2EUsq5y — Dan Tousignant (@ScrumDan) 19 January 2018   12. Overburdening the Scrum team-  Scrum team works in Sprints. Only when one sprint ends, the next one begins. Under no circumstances should two consecutive sprints overlap. In simpler words, teams should avoid working in the upcoming sprint while the current sprint is still on. To maintain consistency, the team should work at a sustainable pace. A Scrum Master should safeguard the team from going beyond this sustainable pace and tackle any situation that might overburden the members.     Concluding Thoughts- Scrum, as you already know, is one of the largest and promising frameworks in Agile methodology. One can in fact strongly say, a paradigm shift has occurred with the advent of Scrum. It is therefore important for the companies to practise Agile in a correct way to build the products and deploy them faster to the market. Therefore, being a Scrum Master, it is pivotal to avoid the above mentioned Scrum problems to successfully launch the product in the market.
Rated 4.5/5 based on 9 customer reviews
12 Common Mistakes Of The Scrum Master And The Rem...

Today, companies are becoming a part of the massiv... Read More

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing. Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.  
Rated 4.0/5 based on 2 customer reviews
1311
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More