Doing agile for the sake of Agile

“All Characters in this play are fictitious. Any Resemblance to any living or dead is only coincidental.”

Characters of the play:

Client -> Some one with the requirements to get it implemented into a product.

XYZ -> Some outsourcing company, masters of Agile – Sales guys.

MgmtTeam -> XYZ business management team for the project.

SM -> Scrum master (we are doing agile, lets not call PM).

DevTeam -> Development team doing the technical implementation.

TechExperts -> Technical experts, special appearance in the play.

MgmtExperts -> Management experts, special appearance in the play.

BSP -> Back stage play.

Hold your breath, it is about to start:

Client: Hey, whatz up?

XYZ: Fine sir, How can we help you? We are blah blah…

Client: I have some requirements and need to build a web application for the marketing of one of the products but I have only 4-5 weeks with me.

BSP [ XYZ: We need this project, this is a big account and we can get projects in future also from the same client. And it is good for our market reputation also in that region.

MgmtTeam: But we don’t have resources available to work on the technological stack asked, but we think we will manage it. Looking at the complexity and tech skills required, it seems that we can do it even after keeping some buffer, 4 weeks is ok. ]

XYZ: We will do it sir. Just raise the glass. Cheers, just think it is done.

BSP [ Client: Good. I just need the things to get done and that also at cheaper rates. Their market reputation says they can do it. ]

MgmtTeam: Sir, we believe in Agile and we are best in it. So, we would like to do the project in Agile way.

Client: Okie, I know something about agile but not very sure.

MgmtTeam: We would like to keep 1 week iteration as total time is not long enough, and we will have demo afterwards.

Client: Fare enough.

BSP [ MgmtTeam: Don’t want him to cry what we have deliver later, better get early feedback.

Client: A bit overhead but will manage it and in the mean time I can explore more about marketing my product and can also get the priority things accommodated.

MgmtTeam: Lets assign a some manager for it, doesn’t look very complex project, even not very experienced person will work and will be cost effective rather than assigning some senior person. As we call him Scrum master, proxy of PM.

SM: yeah, definitely would like to do it, it will be good learning for me and I can also prove that I have got good managerial skills. Lets do it.

No concrete requirements. Nothing Frozen, only deadline is frozen. Agility is the key.

]

MgmtTeam/Client: Lets start. Go ahead.

After 1 week:

DevTeam: Everything is going fine. Don’t have much to demo as it has just started. Lets have it next time once we have something concrete.

Client: ok.

BSP [ Dev Team: Took our own time in learning new technology stack and implementing it in small user stories and tasks.

SM: I can live with first iteration not been much productive. Burn down chart still looking ok. I just need to look after managing delivery and client interaction, will not look into technical things.

MgmtTeam: We got another project, team will handle it. Nothing to care about anymore.

]

After 2 week:

SM: How is it going guys? It is not so complex application, but still we are taking long.

DevTeam: So far so good.

SM: Guys we have demo this week and need to show the client something. We will have to stay back late to get something working.

DevTeam: Finally something is ready.

BSP [ DevTeam: There was a learning curve and setting things initially but we will be able to implement it.

SM: I would say burn down chart on board still looks ok and is manageable. In terms of requirement gathering, I think I am doing good.

]

Client: For the start it is good but I will revive the application and will send the comments. You send me the link where the application is hosted and I will browse it.

DevTeam: ok.

After 3 weeks:

BSP [

Team staying late, getting requirements in small user stories, no time for re-factoring, putting patches on already implemented code.

]

SM: Looks like the velocity and the output we are getting from team is not good enough. Can we get more people in development team.

MgmtTeam: We can but will that help much. We will have to spend more time in getting them up to speed and all other things. Can we somehow get the team motivated and get it done.

SM: yeah, you are right. we will try. But the team tech skills are not good enough. I myself will also have to put some effort in technical things.

DevTeam: The complexity is increasing and looks like not all team members are very comfortable on all technologies and we don’t have time to re-factor and new requirements are coming in terms of bugs also.

BSP [ user stories are pipe lined, new requirements or change requests are coming in term of bugs, not adequate wire frames or reference documents, scrum master devoting more time in implementing things, client expecting that everything will be accommodated, team keep patching due to burden to deadlines, team moral going down.

]

Client: Send me the link again, the old one is not working. It should always be up whenever I want to have a look. I need to show it to the stake holders. And please take care of the list of changes I sent you in last review.

Few days before Deadline:

Client: What is this? (blah blah…sensored ). The deadline is approaching and you have not delivered even 20-30 % of what I asked for.

BSP [ SM: We are trying but the requirements are changing, coming too late also and most of the time in between the iteration also and we need to say NO now, team not skilled enough to meet the deadlines.

MgmtTeam: Okkk, we will talk about why later but what can we do now. Can we get some experts to speed it up.

SM: yeah, definitely need few more people.

]

MgmtTeam: Sir, We need some more time and there are blah blah problems but I assure you that we will deliver it.

BSP [ MgmtTeam: These are new people A, B,C… who will help us to speed up the things.

MgmtTeam: Guys, our main focus should be to deliver maximum functionalities by this deadline and say NO to new changes. Do whatever it takes.

]

MgmtExperts: What the hell this project been, there is so much to be done and this client is also so much pushy asking for everything now, what expectations have we set with him?

MgmtExperts: Ok team, lets prioritize the things from critical, major, minor to good to have. Lets get started. I will talk to the client and will get the things prioritized.

TechExperts: What the hell is this code. There are no quality standards followed, there is no scope of scalability or maintainability , there is so much duplication of code, half of the functionality is not yet implemented, no module integration tests are there. Anyways, looking at the deadlines, we will also have to put patch, to make it working.

BSP [

Whole team puts extra effort, stays late – week ends – holidays, makes the effort to still work as a team and finally makes something to deliver.

]

The judgement day:

MgmtTeam: We have it ready to deliver.

Client: Fine but also fix the bugs when it is live.

All the characters are sitting around a round table:

For client, some how it got delivered and is working.

For team, had a tough time but finally is live. Learned a lot about new technology etc., good to put in CV.

For XYZ, another show case project on Agile, new technology and outsourcing.

The curtain falls and everyone enjoying the …stuff.

…..

So, speaker comes holding the microphone and asks the audiences. What went wrong? and what could have been done better?

No Agile/Scrum process followed properly. It is fine to twist it around a bit to suit the client’s needs but it can be harmful to change its flavor totally.

As the deadlines were fixed, the estimations could have been better. Even the team should have also been involved in the estimations.

Client took the agile in wrong way and was pushy about putting new requirements, change requests and bugs.

Should have frozen the requirements before beginning of the iteration.

Scrum master should have done better managerial job, setting the right expectations to client about being agile, setting the priorities correctly, involving team more into estimations.

Should have educated the team with different agile tools to be used in the project.

Team should have raised alarm when they stayed late on the first day that the things are not going well, need to re-prioritize the things.

Looks like team’s technical skills were not sufficient enough, should have spent enough time to get everyone up to the mark.

Should have done like pair programming to share knowledge among everyone, kind of mutual code ownership.

Too many risks taken by the team thinking that it will be done and not conveying the state at the right moment.

Risks and impediments were not anticipated properly.

Looks like the code quality was below mark and team should have spent enough time to re-factor the things while reworking on the same piece of code.

The module integration test cases should have been there.

Looks like there was no separate tester for the application. No dedicated machine for the testing. No continue integration builds.

Should have taken some steps to motivate the team, may be anything like go out for party or beer.

Roles should have been cleared for the team members, like how much time the scrum master going to spend on development.

Should have selected the team who are good in that technical stack.

Initial consideration to think that the project is very simple turned out to be big mistake.

Thank you note by Speaker (mic still in hand🙂, hope you enjoyed it) :

Agile into waterfall – paradigm. Everything worked ok at the end but in the process of making it, from start to end, everyone in the play is equally responsible for the over heads. Whether we talk about the client, who is not well aware of the real meaning of being Agile or the management team which is more interested in getting the things done and try to please the client by saying yes every time with out discussing the real situation with the team/client. And the development team not to show the real picture and should talk more about the complexity or simplicity in the implementation and be more open about the things. The above mentioned points are not in any particular sequence like process wise or infrastructure issues or technology wise, it is not because it can’t be divided but because it is all about working as a team. Agile is not just about being open for the changes, both the client and team should understand it well.

One Response to “Doing agile for the sake of Agile”

This post has a lot of good thought in it, but it might be helpful to revise it a bit to help people digest it better. I think I know what you are getting at, but unless your reader has experienced good agile, they may not see the issues experienced in your “script” until they get to the curtain close bullets at the end.