Is Agile MicroManagement?

I came across this very funny question recently. And I refer it “funny”, because I find it so.

From experience of working in Agile environment for years now, one thing that I found common in all failed agile projects is that the project teams always blamed it on the overall methodology and associated processes and none of them appreciated the fact that they never got the Agile understanding the right way. And at this point in time, I want to go back to something I read about Agile. It goes as below:

Agile is like teenage sex

Everyone says they are doing it.

But most probably, no one is doing it.

And whoever is doing it, is not doing it right

 But fact remains that there are project teams that tried Agile and failed. And they strongly feel the failure was completely because the way Agile is set up – “Well … it exposes the entire team to the customer with little or no ability for the project manager to manage the situation. There is way too much of involvement from the customer. So much to get done in 2 weeks and with ‘welcoming the change’ philosophy, developers are always on their toes. And QA gets so little time to test in 2 weeks. To top it all, customer has so much of visibility into everyday tasks that they are actually Micro Managing the Project Team”.

 Hold it … right there!!!

 I hear some souls nodding their heads and saying “absolutely … every word related to the project failure justification is true”. And I don’t blame them. That said, it's not that I agree with them. But when I say, I don’t blame them, my point is – what’s the point in blaming a kid who wants to play with fire and burns his fingers. First the kid does not know it's fire, second it does not know it will burn, and third it does not know how to use fire the right way. And ‘fire’ here is only the analogy and not a parallel between Agile and real fire. Given the choice, I would like to call it Ice than fire. But then you might not get my point.

 So basically, if you do not know how to use a tool, you probably are going to use it the wrong way and break it further than not using it at all. So here is what I have observed on all failed Agile projects.

1.       Are we practicing Agile or we are Trying it out? There is a big difference. You would say, if someone is doing it first time, then they would definitely try it once before practicing. Fair point. But when you try it, you do not have to give it up with one or two failure. If that was the case, Edison would not give us the light bulb. So if you know you are trying, then limit it to Trying. And if you want to practice it, then first understand the right way. Don’t confuse between Trying and Practicing.

2.      Agile Project Team – the keyword here is TEAM. So it's important to understand if the project team was working like a team or was it a group of individual performers busy completing their own work. This assessment needs to be done during the course of a project, during the course of a sprint. A post-facto analysis will not help and will produce biased results.

3.       Most importantly, did the Team and everyone on the team understood the Agile the way it should be? Did you really understand the importance and intent of a process or did you go Verbatim way? Do you believe Agile says no documentation or do you understand Agile calls for only necessary documentation? Do you believe Agile means produce as fast as possible or do you understand “as fast as possible expects you not to compromise on quality”? Do you believe delivering on commitment is critical or do you understand that you may go wrong on commitment but what you can deliver – though below committed levels – should be with TOP quality? Do you believe that customer is allowed to make changes or do you understand when to say NO to these changes and recommend the customer to wait till next Sprint? Do you believe Stand up is a status reporting meeting or do you understand it to be an opportunity to collaborate and communicate? And so many beliefs versus understandings!!!

4.      Your customer cannot manage you if you manage the Process. Does your customer understand their role? Do you communicate it to them regularly and frequently? Is your team mature enough to give a necessary push back in line with defined processes? Is your customer trying to get visibility into your Sprint or are you providing maximum visibility to your customer so that they do not have to try to. Is your Sprint Backlog a sequence of tasks or does it provide the clear visibility into your plan to get something done?

5.      Do you have right skills on the team or are you trying squeeze in some non-performers for higher margins? Does your team understand the processes or do they even understand the importance of the same?

And many more such questions you would need to answer, before you blame it on Agile next time.

Hope you would find these answers. And if you could not, just reach out!!

Beautiful Colorado on Bucket List

Flying over Colorodo as I type and the view is amazing. Ultimately clear skies with visibility beyond horizon horizontally and up to ground vertically (48,000 feet). And it’s just awesome. The Rockies from the top are absolute amazing and a sight of lifetime.

Started from Portland, OR this morning and on way to Phili. Was too concerned of getting on the plane, but the view changed my mind. Thanks to the change in schedule and I had to take early morning flight. The takeoff itself was eye-soothing. The green mountains and huge and log river makes it an impressive eyesight. And before I could admire the beauty, we were over this dormant volcano mountain. Great view. The mountain ranges are not just ending for last hour or so. I miss my camera on this flight. The landscape is so picturesque that I would be taking 100s of pictures today. The mountains with green tops, the brown slants, the white edges, tall and short look so beautiful. And the winding rivers only add to the beauty.

While I could admire the mountain ranges, there comes the plauto, miles of brown land with patches of green and blue. And see these roads ... so straight, so long and so lonely … there absolutely nothing on either side. I was in US for about 8 years, but never made it to Colorado ... regret that. Probably one of very few things I regret in my life. I should have been here and experienced the drive on these roads. The heat will be unbearable I know, but so was Snow in PA and crowd in NJ. So this could have been some experience.

Should be on my Bucket List. The woods may be dark and deep, but for sure these are the miles I should go before I sleep

Disciplined Agile Delivery ... so called DAD

Well, here we go!

In my last post, I mentioned about this Webinar on DAD and frankly ...Liked nothing about it. No denial the methodology is good ... well it has to be coz its an extension of Scrum. Or let me take that back. Its actually Scrum spelled incorrectly. It only rips off Scrum clothes and puts on new one .... here "Made In DAD" .. stamed and done. Well that "Definition of Done" is a little nasty I would say. And what I hated most was the way it was presented. Many people when promote Agile make a mockery of Waterfal (wrong in first place according to me), and here the presenter just presented Scrum in bad light, thinking it will lighten up his DAD a little more. Thats like Duracell saying Sun is not bright today :)

Primary Roles - StakeHolder, Product Owner, Team Lead, Agile Team Member and Architecture Owner. .... Bang!! No Scrum Master, know why? Because they say the role does not add value. A team without a leader will miss the target. Hmmmm... interesting, but not right I will say.

Secondary Roles - Domain Expert, Technical Expert, Independent Tester, Integrator, Specialist ... Aaaha! Gotcha!! Scrum suggest against specialized roles, but DAD wants to see you do something specific you know (otherwise you may just get into bad company and get drug adict). Is it not adding dependency on particular team member? And isnt Scrum actually talk about shared responsibilities to kill the dependencies only?
(and the slide read "People First" ... don't see where!!!)

No Sprints ..... oooopppsss! Thatz a biggie. Without Sprints, how will you develop incrementally. Thatz a tough one ... but wait and thanks God ... there are Iterations. Oh .. so thats the difference. It took me a while to realize the difference though .... dumb me!!

DAD claimed it's Learning Oriented. Who sasys Waterfall wasnt learning oriented. Give me one process or methodology that is not Learning Oriented. Well, DAD's learning oriented approach revolves around Requirements Envisioning, Retrospectives at end of Iterations, Proving the architecture with working code (???), Training+Education+Mentoring+Coaching (Scrum Master??), Tracking Improvements (retrospective??), Sharing Skills through non-solo developments (eXtreme Programming?).... this reminds me of something. How many of you have seen that "Friends" episode where Joey writes a letter. Well, it wasnt any different ... "sharing skills through non-solo development" .... huge ... keep it simple dude. "Pair Programming" ... we understand it. We dont have a mobile Thesaurus yet :)

Oh oh .... here. Take this one. DAD's concept is "The Agile 3C rhythm". Coordinate, Collaborate, Conclude.... Joooooeyyyyyyy ... where have you been maaaaaaan?

wait wait wait ... and they dont have daily "Stand Up" meetings. Know why, coz it does not have the punch. The "stand up" does not convey the message. So we replaced it .... any guess .... take another minute and tell me .... don't TimeOut on this one though.

And then the cherry on the top. Enterprise Awareness - Optimizing the Whole (hey ... thats a hole with W ..don't forget, they have not renamed it yet. Or may be Joey didn't find this synonym in his Thesaurus). So, here are the Enterprise Awareness guidelines.

• Follow Corporate Conventions / Standards (coding, UI, data, and many more)
• Enhance Organizational Ecosystem (reuse, infrastructure, EA team)
• Share Learnings (Agile Center of competency)
• Interact with other (potentially non-agile) teams (PMO, QA, Governance, EA).
• Don't know what these bracketed teams are non-agile though. May be, thats why DAD asked me to interact with them and find why they are non-agile and that much better.

(ok .. Time Out. so we dont have daily stand up meetings, but don't worry .. we have Daily COORDINATION Meeting. Hmmmm .. that helps!!! I was starting to wonder who should I discuss my status with. Thanks!!)
Well, 2 hours wasted. Don't ask me how many Person Hours. I know I should have followed the Agile Principle and walked out of the Webinar. But being married for 10 years now, you need to stick to listening some times. It was just one of those days.

Anyways, I have a new sign on my office door. "Beware of DADs". You better read it!

Disciplined Agile Delivery .... or something like that

Today I attended this Webinar subjected "Disciplined Agile Delivery". From the subject line it appeared it must be something that will teach you how to deliver projects using Agile Discipline. Well, did not turn out to be true. Rather, it is a new framework that IBM has come up with and the webinar just rediculed the regular Scrum process.

I will write in detail about the so called DAD framework ... but for now only two things ...
1. It just took me back 1 year into time ... when I read about "PlayBall" framework. Nothing new ... just reword the Jargons .... and hurray .... we have a new framework

2. There are two ways to be famous ... either be good .... or show someone/something as bad ... This webinar chose later ... candidly, not a great way.

More to come on this topic. (Posted a new blog about it here http://dineshmadne.blogspot.com/2011/05/disciplined-agile-delivery-so-called.html)

Who should be on your team?

We are starting this new project with a customer and during the envisioning phase someone asked me a question about the Business Analyst being part of the Scrum team. The question was "here we have a BA who needs to work on something during the Sprint, so should she attend the daily stand up calls?" To me the answer is straight ... but let me get that answer to you by using an Agile practice I all as "Ask a Why" (or "Why 5").

So let us ask below questions to ourselves and see if we can get the answers. Is this BA going to work on something
- that is going to affect or contribute to the Sprint Deliverable?
- that may become a bottleneck if not completed?
- that may have some dependency that the Scrum team is going to deliver?
- that scrum team including the product owner will be interested to know the progress on daily basis

If the answer to any or many of above questions is affirmative, then yes the BA should be part of the daily stand up - which also means the BA should be part of the planning meeting, she should have a backlog (as part of your Sprint Backlog), should provide status and report bottlenecks and also attend the retrospective if possible (you never know, the same devil may show up again in some sprint :) ).

The scrum master was intelligent enough to get the answer based on the questions I threw at him and here we are ... working on the Sprint which is going on smooth. And once again "Ask a Why" worked.

Is Scrum Master the toughest role of Agile?

For past 2 weeks I am in Boston on a business trip. And on a lonely evening I was just thinking about the change of role that I am experiencing from what I was 5 years back and what I am today.

5 years back, most of me was a Project Manager - busy with managing project, assigning tasks, running behind teams, writing status reports, convincing customers, fighting with management, yada yada yada ... the list just goes on. I dont fully remember how satisfying the days were, but don't even think I had any peaceful days.

Today, most of me is a Scrum Master and let me say "I like it this way". No team to run behind, no customers to fight with, no management disagreement (well, most of the time) and most importanly, I don't have a responsibility ..... wait .. let me take that last one back. "No Responsibility" ... that does not sound right.

And this is the exact thought that struck my mind. Being Scrum Master has eased my day to day life, but has it made me less productive, is it any easy compared to being a Project Manager, has it taken the challenge out of my job ... and many such questions. There as no direct answer, so I had to rewind the 5 years and start from where I had left. A One-on-One comparison of what challenges I had then ... and what challenges I have today. And after a good hour on the thought, the picture was very much clear.

Being Project Manager was easier than being a Scrum Master.

• It was easier to ask a team to do something and push them forward. Believe me, it is very difficult to convince someone to do the right things.
• It was easier to prepare my project plan with my estimates and assign the resources. Believe me, it is very difficult to have every team member get their Sprint Backlogs ready before start of the Sprint.
• It was easier to demand I want it by today evening (max by tomorrow morning). Believe me, it is very difficult to say Alright, do it by tomorrow morning, but ensure it is done.
• It was easier to get the status from team members and present it in the Green Zone to customer. Believe me, it is very difficult see the team exposing the real status on daily basis.
• It was easier to take the project decisions and own them. Believe me, it is very difficult to coach a team to be empowered to take the decisions and respect it, fight with management for protecting the team decisions.
• It was easier to prepare a 6 months /1 year / or longer plans and blame everything on Change Requests. Believe me, it is very difficult to say, changes? so what?
• And many more things .... but the most difficult is to create this fun loving environment, a healthy and faith based work culture with customer and letting it go so that team can manage it. It is just difficult to see stuff not happening the way you like. And it is very difficult to say "team did a great job" knowing that you probably would have done the same way.

So seriously, it was easier to be a Project Manager than a Scrum Master. But not necessarily Satisfying. I realize, being a Scrum Master today I do have challenges of empowering the team and coaching a customer. But at the end of the day, I am satisifed to see customers gets what they really want, teams are happy and are committed to the work.

No big deal that I am not in control. All that matters is "Things are still going fine!!"

User Stories or Use Cases

This seems to be the question of the month. I got it quite sometime in last few weeks. So thought of penning some of the discussions, thoughts and research I did on it.


As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.


Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.


User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.


I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.


The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.


The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.


The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.


Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?


I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.