Agile Launches: 2 weeks before launch

Two Weeks before launch can be a very interesting time for anyone in the business of launching anything. Be it a book, a rocket or a software application. I can self exemplify. When my company very recently launched a really big product to millions of fans who were awaiting it eagerly.
I'll get straight to the point. Around Three weeks before launch we adjusted our process a bit and went into Triage mode. We did a code freeze on our main branch and there on only committed to working on bug fixes. Instead of user stories we only had bugs which could be fixed in a day or less. The bugs were divided into Priority 1's, 2's. 3's and 4's. Each priority level was assigned a level of criticality all approved by each team member. We still did our daily stand ups but instead of answering the 3 questions wefocussed on the priority of bugs that were open and team members self assigned it to themselves.

Apart from that we also did daily releases out to our pilot environment available to our internal UAT group. There were a couple of people who monitored graphs and metrics related to performance of the servers, web-heads and databases. We did simulated performance tests reconfigured our servers based on the results.

Around Two or Three days before launch, we shifted our process even further collocating to a war room during working hours. All teams members including PO, and SM were collocated in a conference room during this time. I made sure all resources had what they needed and were not impeded. The business folks were right next door and kept close contact with our development team. At times it seemed a little disruptive to the development team but it was well worth it. This phase was agility and transparency to the core. The business folks saw the inner-works of not only our operation process but our operating product. There were feature requests that were refused. There were emotional moments. In the end, everybody was mature enough to know it is all part of the game. It was all part of the launch.

On the day of the launch, the privacy flag was removed and our Application went live.

There were tons of users flooding our servers when we launched. Nothing crashed. It all went smoothly. Everything seemed to fall into place. The reality of it was we were so agile and had practiced our launches several times courtesy our 3 internal launches, that it felt like just a practice drill. We had done it all before. Now it was just to a larger audience. We had done our performance tests, and knew what our servers could take. The mystery that existed before did not during launch. All thanks to hard working and smart team members and iterative development.

Off-course, celebrating successful moments is always important, I don't care if you are agile or not. The reason why this celebration is important it is that it gives an opportunity to the holistic team to meet and greet each other, many of whom who may not have actually met each other in person. Cross-functional bonding plays a very important role in a companies success and they often happen during these kind of celebrations. Anyway, we had a grand celebration and bonded very well. Right now (after launch) we still have a support team who follows this triage format. We thought it would be a good idea for the support team to monitor graphs and push bug fixed in post launch. Maybe this support team will become a core scrum team which only does small feature development and bug fixes? Who knows? We will inspect and adapt and figure it out.

We also do have a feature development scrum team which takes on larger chunks

of work and work in 2 week iterations. In fact that is what is currently happening. The feature team have a prioritized list of user stories and they work in a scrum te

am cross-functionally.

Now for some real pictures of just days before launch of team working in war room format. If you notice the business folks were in the room across us.

The Agility of the Boise State Broncos

You can love them, hate them or ignore them but you have got to appreciate their agility.

I came across an article written by Katy Moeller who works for a local Idaho newspaper company. Having seen how Boise State do what they do I was not surprised at all by the quotes mentioned in her article by some of the members of the Boise State Football Team.

Here are a few quotes from the article that without any doubt sound agile. I have tried to put in my not so important 2 cents after each quote. Hope it is useful.

"Simplify. Focus. Be here now"

This is Chris Peterson's ( who is the Boise State Football Head Coach) fundamental principle. There is one key agile manifesto principle, "Simplicity- the art of maximizing the amount of work not done". It relates very clearly to "Simplify". "Be here now" really means, avoid planning too far ahead, focus on the job at hand, get it done, move on to the next task in priority, and keep going.

"Some of those who know Petersen best — former players — say it’s Petersen’s grasp of the big picture, as well as his OCD-like attention to details"

You might think this quote is a little contradictory to the first one but what it really means is get just enough of a holistic picture but know that which task you have to focus on at the present time. In Agile we do Release Planning which gives us enough detail on the big picture. Agile teams get into more detail when we do Sprint planning and while sprinting they focus on the current Sprint tasks and pay attention to detail. It is imperative to not get distracted by work that is laid out too far down the lane but it is always a good idea to take a quick peak at the big picture periodically.

"The thing I loved about Coach Pete was his Sunday meetings and everyday meetings said Vinny Perretta, the running back/wide receiver who threw a touchdown in overtime during the 2007 Fiesta Bowl"

Well Scrum meetings don't happen on Sundays but it seems like Coach Pete did have his own version of Daily scrums for a daily sync up.

”He didn’t want to be looked at as somebody you can’t talk to — if we had a problem, he wanted us to come to him, said Richie Brockel, a tight end from Phoenix whose role as a team captain in 2009 didn’t hinder him from earning a master’s degree in accounting"

One of the Agile principles is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" An Agile team member does not need to talk to a secretary to contact a manager or client or stakeholder. The team is well empowered to just walk over to anyones desk for a face to face conversation. In an agile company issues are handled in a transparent fashion using face to face conversation.

"I’ve never been around a place that took so much input from players like it was at Boise,“ said Bush Hamdan, a former Bronco quarterback who is now an intern with the University of Maryland football program"
"Players have helped define some of Boise State’s defining moments. ”Statue Left,“ which famously won the 2007 Fiesta Bowl, featured a tricky hand-off designed by reserve quarterback Nick Lomax and a hurry-up pace suggested by Hamdan and fellow backup QB Taylor Tharp"

”He treats people the right way and empowers everybody in the program so they feel like their role is as important as anybody’s"

Good Agile companies believe strongly in the bottom up approach. Agile teams hear as much input from an intern as much as they hear from a Manager. The bottom line is that irrespective of hierarchical level in the company everyone on the Scrum team has the right to voice an opinion as long as they are Scrum pigs. Empowering teams and giving them the right tools and environment is key.

http://www.youtube.com/watch?v=D6Wfg0n2EE8

”It’s a good system. It holds you accountable to your teammates"

"A list in the locker room was posted so that players would know whether someone wasn’t pulling their weight in the classroom"

Apparently Coach Pete was pretty good about making sure the kids on the team were disciplined universally and attending their classes. There were consequences for missing their academic classes and they were held accountable not only by their coaches but by their team mates as well.

"Every day, they’re focused on their process,“ Hall said. ”It’s not once in a blue moon."

This quote is probably the most agile of all of the above. Agile teams plan every day, they inspect and adapt and respond to changes. It does not happen once it a blue moon. The daily standup is a good focus point, so is a Sprint Review, so is a Sprint Retrospective, and so is an ad hoc offline huddle happening after Scrum.

"He’s really big on learning from the process and analyzing things in the past and trying to improve on them, Brockel said"

Coach Pete recognizes the importance of a periodic Sprint Retrospective and that is agile.

"Organizational culture is so critical."

In order to be a successful agile team everyone on the team needs to fit into the organizational culture. Agile teams are collaborative, cohesive, pair up a lot, swarm a lot, huddle a lot, use a lot of common sense, hold each other accountable, and have fun while doing getting stuff done.

References: http://www.idahostatesman.com/2010/10/16/1381300/the-man-with-the-plan.html

The 300 Spartans were Agile!

Was the Spartan army agile? Below are some facts about how they did what they did. You can judge for yourself.

"Much of why a Persian army of perhaps over 100,000 soldiers was stopped by 300 Spartans brings into play the role of strategy and tactics in any successful ground war"

"History tells us that young men being groomed for the military in Sparta entered their training in childhood leaving behind family to devote every moment of their lives and every fiber of their beings to becoming fierce and effective soldiers. Their physical training was intense and it never ended"

"We do have to recognize that in the end, the Spartans were defeated"

"The pass was narrow so when the Spartans took their position at high ground, they could block the pass with numerous rows of Spartan defenders to repel the Persians"

"The Spartans were armed with tough and well designed armor and weapons in contrast to the Persians who wore no armor and who fought primarily with inferior short swords"

The above quotes make it pretty clear that:

1. They possessed an army of men much greater than 300 but still they preferred to go with a smaller squad. They believed in working in small cohesive teams.
2. They believed in keeping a constant check on quality. The intensity of physical training never ended. A check on quality is a never ending process.
3. They believed in measuring success by measuring how efficiently they defeated the Persian army. Although in the end the Spartans were defeated and most of them died but what mattered most to them was how efficient they were while doing what they did. In software development efficiency can be measured by the velocity of getting user stories done. Velocity increases when user stories are tackled efficiently by improving strategies used.
4. They used the pass of Thermopylae to their advantage. Think of the pass as a Kanban swim lane, and think of the persians as numerous requirements coming at you at random intervals in the swim lane. You can crush them one by one without worrying about the others that are not in the swim lane yet. In Kanban you have the advantage of forming several passes as and when you require them.
5. The Spartans had well designed armors because they believed in high quality design and security.
6. The Spartans were defeated but they still achieved much more than any other army could have. It is much like a Sprint team ending it's Sprint. Thankfully no one dies while building software but in agile teams success is measured by how much they get done and how efficiently they get it done more than anything.

The above 6 points in some way or the other reflect some of the core agile principles. If you think about it from a software development perspective the persian army is more like hard deadlines combined with changing requirements and tough clients. The great spartan army is more like small cohesive scrum teams that work in incremental fashion, have a clear strategy, battle all odds and meet tough deadlines much beyond their waterfall capacity and off course everyone gets to live!

Experiment with Sprint Planning

"Methodologies just add more meetings. It just slows us down and makes us unproductive!"

The freedictionary.com definition of unproductive is "Not productive; idle."

Agile does not mean no planning. In fact Agile means you plan all the time. If this does not make sense then I advise you to go read the 12 Agile Principles here. Please try to dig deeper into them and make the 12 principles work for you in your day to day work life for at-least a 2 month time frame. If you really try and make it work for you and try to implement the principles in your day to day work life then probably you would understand what I mean when I say you plan all the time and you would understand what being Agile really means.

When you are Agile, you avoid phase driven planning sessions. Planning happens rhythmically and at an appropriate time involving only the required people. Also a lot of impromptu planning happens during the software life-cycle. This planning is mainly based on the inspect and adapt principle and the inspect and adapt principle is based on the empirical process control theory.

In Scrum we plan during the Daily Stand Ups, Sprint Reviews, Sprint Retrospectives and off-course during the Sprint Planning meeting. Planning == inspecting + coming up with adaption strategies. Sprinting == wasting no time in phase driven philosophies and implementing the adaption strategies to ship out working software to users.

Let's assume we ban all the Scrum meetings and just start working on stuff organically. In this scenario we would need some really awesome organic osmosis to happen to make things work isn't it? Organic osmosis does happen, but only in small scale teams who know each others working styles really well. When you try to scale organic osmosis, there are high chances that it may fail terribly.

A key principal in Agile Planning is Just in Time, and just enough planning! This balance has to be maintained always, while being agile. Implementation time of the User Stories should be when the requirements meet the INVEST principle. Independent, Negotiable, Valuable, Estimable, Sizable, Testable.

Arguably, if you fail to plan, then you would plan to fail!

Prioritizing Story Cards in Scrumban

How the heck do I prioritize this?

If you are a passionate Product Owner this question may have popped up in your head several times while grooming your Product Backlog, especially when its nature becomes very dynamic.

In Scrum, a tool mainly used for prioritizing is the ROI calculator. It makes sense to use the ROI calculator when the User Stories are chunky and the product Backlog is more stable but when you are doing Kanban or Scrumban managing story card priorities is a completely different ball game!

One could argue that setting deadlines over ROI values is a more sensible thing to do in Kanban. It may not imply that ROI calculations don't help at all and should be banned but when the Product Backlog is so dynamic, ROI numbers don't really help much in arranging stories according to priority. Everything seems to have a high ROI! What is more likely to differ though are deadlines on the stories. So why not use deadlines to prioritize work? It is also a very natural thing to do.

Setting deadlines on stories really puts priority in perspective for the Team members doing the tasks and it also helps the Product owner wrapping his head around a dynamic Product Backlog as far as priorities go. Off-course this is not a silver bullet but just my observation.

Other crucial aspects to use while prioritizing stories are revenue or loss, and availability or unavailability of resources.

Task-board Experiment

Task-board Experiment

Very recently I used a Taskboard for a couple of Sprints for one of my Scrum Teams who had not used it ever before. This article will discuss that experience of the Team. Some of the things discovered about the experience were very interesting because they were mostly so contradictory to what a task-board is perceived for doing for a Scrum Team.

Flip sides to the coins discovered (not trying to be destructive but realistic)

Transparent yet not transparent:

The work being done became transparent BUT at the same time it was not transparent because the notes on the post-its (on the task-board) were not clear to everyone because of limited real estate. Hence detail was missing.

Light weight yet not light weight:

It was very easy to add user stories and tasks because all that was needed was write the required stuff on a post it and stick it on the board BUT due to details missing for the User Stories and tasks it was considered heavier because of having to use 3rd party tool to maintain documentation that linked to the stories on the task-board.

Priority Shifts

The shifts in priority are troublesome to handle on a task-board because a lot of shifting of post its is required BUT it eventually comes down to the experience of the user using the tool, whichever tool it maybe.

Collocated Team Members:

It worked great for collaboration between Team members who were collocated BUT non collocated Team members (located in a different room next to ours) found it inconvenient to track their tasks from task-board located in a different room.

Most of the Team members agreed in the end that it was not the task-board that failed completely for them but it was how some of them used it. Some genuine limitations were discovered like non reliable archiving, and limited real estate to include detail in stories and tasks. This experience taught us that it may not work for everyone. The heaviest of tools can feel lightweight for Teams who are familiar with the particular tool.

Experiement with Sprint Review

"It's a waste of time!"

What do you think that statement really means?

One imperative question pops up in my head whenever I hear that statement.

1. What is the true meaning of "waste" and "time"?

Waste as per thefreedictionary.com is defined as "To use, consume, spend, or expend thoughtlessly or carelessly". Waste has a very specific meaning. On the contrary Time is relative. Time is defined as "An interval separating two points on this continuum; a duration". So Clearly Time is relative and changes based on the two relative points.

Let's magically teleport ourselves into the delicious world of the Cake business. Let's assume that we are dealing with a REALLY PICKY customer and several other COMPETITOR CAKE BAKERIES. The PICKY customers want their cakes super customized. They are really busy but find some time to explain what kind of cake they need. Say one PICKY Customer wants a chocolate cake with 5 layers of alternating cream and chocolate. He also wants five cherries on top of it and it also needs to have the right amount of sweetness. The cream should be medium thick in all the layers and the icing on the cake needs to be of spectacular quality.

Two broad approaches to building the cake may be taken (in the Cake builders mind). One would be telling the customer that he will receive his full cake in a couple of days and spend those 2 days making sure the cake meets his requirements. The other approach could be to build a small piece of the cake in an hour or 2 and (considering his pickiness ) have him come to taste that small piece.

Here is the point I am trying to make, the time we spend inviting the customer and having him taste that small piece and getting his feedback would be much lesser than the amount of time spent building the cake all over again because he does not like the complete cake (built in all or nothing fashion). We would rather waste a small piece of the cake than waste a whole cake. So where is the wastage happening really? In checking at regular intervals with the PICKY Customer if the cake we are building are as per his standards or in the time spent building a cake which he definitely would not approve? Why on earth would you risk throwing away a whole cake vs throwing away a small piece?

The TRUTH of software development is that it is a BUSINESS. The customers are picky. Yep there are. The customers needs are constantly changing. If we don't give them what they want they will just move to a different product without a blink of an eye.

A Sprint Review gives an opportunity for the customer to take a sneak peak at what is being built. He gets to give feedback. If he realizes that that is not what he wants, the team that is building the product has the valuable opportunity to tweak the product as per the customers needs rather than fail.

So is this really a waste of time?