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?

Pre UAT - the notorious professor tactic!

Pre-UAT. Why it cannot be underestimated.

The importance of Pre-UAT is often underestimated. There are quite a few companies which I know which think Pre UAT is a waste of time, thank God it is not my current company. Pre-UAT in my mind is all about getting the customer involved early to deliver the most potential shippable software early. Not months down the line. Really ridiculously early. Why? Because as product builders, often times while building our awesome product using our awesome techniques we forget that the customer is the one who has enabled all this awesomeness for us in the first place. We are the flame. Never forget what sparked us into existence or else we could be extinguished without knowing when and how it happened. Unless off course you are the spark and the flame both.

I thought the best way to describe the benefit of a Pre-UAT is by

giving an example of a notorious professor I had taken a class with in school. He taught

Chemistry and Math. I remember much before the final exams he used to set unofficial internal deadlines pretty much spontaneously on the syllabus he had covered up until that moment. The internal deadlines often did not make sense to us students because they covered partial concepts and partial chapters which were a part of a bigger concept which was not yet comprehended by us yet. Well you must be thinking, how is that any different from a mid term or a surprise test? In my mind the fact that the midterm is a planned exam which happens at a fixed time and date makes it ineffective.

What the notorious professor did was announce a date for a test on the syllabus covered so far, tell us our final grades would be affected by it and then after we had focussed all day everyday until the day of that test on the syllabus he would casually announce in class on the day of the exam that he had cancelled that "life changing" test because of some petty reason. It generally used to leave us hating him and relieved at the same time. What we did not realize was that it made us really ready for whatever was taught until then. If we had to give a final exam with that scoped out syllabus, at that moment, we would kill it! In agile software industry talk, we were truly shippable. We had potentially shippable working software and the beauty of it was that we did not even know it.

Scrum in a subtle way does the same thing. Now ponder over the above paragraph for a minute and send across any questions that might pop up in your mind right this moment without hesitation to sid@sbnation.com.

Bye.

Why the Task board?

What is so cool about the Task Board?

The world has become so complex that it is quite natural to ask that question. The first instinct almost always is, why is this so simple? Why not make it more complex and more interesting? The irony is that while we think we are making it easy to solve a complex problem by using a complex tool, it actually makes the original problem more complex at times.

For folks who want more tangible answers, here are some specific benefits

of the Task board.
1. Simplicity: Visual indicators of work in progress, work to be done and already done work being right in front of team members (pigs) and chickens.
2. Better Collaboration: Encouragement of Individuals and Interactions via task board (which is right in front of the Team)
3. Usability: Ease of moving around of tasks

without software tool overhead (very less overhead)
4. Transparency and Accessibility: Any pig or chicken can walk in a Scrum Team Collaboration room, look at the task board and get a good grip on how the team is doing.
5. Time Efficient: Save at least 4 times as much time as compared to heavy Scrum tools because of team swarming around tasking.

Why do all the things I mentioned above happen?

The answer is simple. The damn thing is right in front of you all day or in at least very close proximity! It's staring you in the face all day. You can't help but look at it. Ignoring it is impossible.

The ease of access is also amazing. Typically, team members huddle in a collocated area often looking at the board and discussing the plan of action for a task or tasks in process and then implementing the tasks. Once they are done, the done tasks are moved over to the done lane and they huddle over the next tasks in the same way. This happens in an incremental way almost all day. It is so amazing how a giant visual indicator board can make such a big difference to the way a team collaborates. The key here is being on task and track constantly while collaborating, which a task board helps you out with. What is automatically facilitated in this whole process is an informal task burning ceremony which unknowingly boosts the team morale. IMHO, the act of physically moving over a bunch of done tasks as a team or pair, in a collocated area for some strange reason makes the team feel more accomplished than using a software tool. I think one of the key ingredients of a successful team is them being aware of their success, and them knowing their true potential. The task board makes this possible for the team because of it's amazing transparency and almost weightless nature. The team saves ridiculous amount of time, because they literally swarm on everything. They also physically swarm during the tasking in Sprint Planning which saves a lot of time as compared to one person tasking things out in a Software tool. It encourages face to face communication. The list goes on. I can write a complete paper on it's advantages but I'll stop here.

My final smart ass statement is that, you have to actually use it (correctly) to know what I am talking about. Until then, it may just seem like something someone is asking you to do which may sound skeptical.

Was Leonardo da Vinci Agile?

Was Leonardo da Vinci Agile?

We all might be familiar with Leonardo di ser Piero da Vinci the great Italian polymath

who is world famous for his Mona Lisa portrait. He was also known as a man of "unquenchable curiosity". Perhaps

this curiosity might have led him to a perfect way making his world famous Mona Lisa portrait.

It has been said that Leonardo would first create a detailed under painting and then apply his colors in transparent glazes on top. If we put ourselves in Leonardo da Vinci's shoes for a moment, what would be our strategy with the goal of being commissioned for the painting? Would you sketch the whole drawing i.e. the lady sitting on a chair with a smile and the background and then paint it or would you first just focus on the lady's face - sketch it and paint it completely and polish it, then focus on her hands - sketch them and paint and polish it completely and then her dress and so on?

In agile software development (of web content especially) we are often faced with this same question. Well the answer really completely depends on the core and non core features of your product and your release strategy/plan. Every product has a release done criteria. The release done criteria is derived from the release plan and the release plan is derived based on the nature of the product, it's core and non core features and their work flow. How the users would really use the product is key to know here.

To speak with more realistic deta

il, here is an example. Now think of a shopping website with several screens that shoppers access. Every screen would have a bunch of features. Some of those can be broadly classified as core features and non core features. A Core feature would be a feature without which a website or web app would have no value. For example, not being able to login or create your own account, select a product and check ou

t and by being able to make a payment would make a shopping website useless and would be in

valuable to both the shoppers and the shopping website! Now a non core feature could be having the option of a speedy checkout or having the benefit of viewing similar kind of products as prompts or reminders before actually making the final payment. The core and

non core features would change based on several factors like the market, the users current trend of needs, events etc. These identified core and non core features would drive sequence of work to come in iterations and also the done criteria for the iteration.

Moving back to the painting example, lets assume that Le

onardo might have had to pick out the core pieces in his potrait of mona lisa while discussing the initial vision of the painting with the commissioner, so what would they be? Would it be the lady herself, her face, her elegant smile, her crossed hands, her hair, her dress? Would the background, the landscape, the trees, the chair the lady is sitting on be n

on core features? That is what it seems like but I am no artist, so I'll try not to answer that question but the key point here is that knowing the core features that would drive the product and shipping them out first is most essential. What is even more important to know is that the core features compliment each other and cannot be released or shipped without one another. For eg. a login to web app feature would not make sense to be shipped without a check out feature screen.

So what do we do?

A technique which has worked for me in the past is building the core features and making the complete workflow functional and "working software" iteratively. Rather than building one functional core feature and polishing it till it's shippable, build the the set of core features based on the release plan even though they are not polished in the first iteration, and then use the next iteration to tweak the work flow based on customer feedback, then polish the whole thing and make it shippable. This is a common sense way of doing things. We know as a fact that certain collections of core features are just needed (together) to be able to call a product 'shippable' so why silo the core feature building process?

The non core features may also be squeezed in at times as long as it is in the release plan, but what is more important to focus on here is a technique to do incremental and iterative software development most efficiently, while using common sense.

Finish 2 Finish Approach in Agile

Finish 2 Finish Approach

Don't run a relay!!

A dangerous path that new Scrum Teams need to avoid is a Start to Finish approach. What this means is the Scrum Team spends the first Sprint doing Analysis and Requirements gathering, then the next Sprint it does Architecture and Design of the System, then in the third Sprint they build APIs and build basic architectural components, and in the next they start actual development and in the next Sprint they test, we can clearly see which way this is going.

Another equally dangerous path is including analysis, design, API building etc, feature coding, testing all in one Sprint (which is correct) but waiting for one activity to end before the next can start. This again is a Start to Finish approach. Both these paths can be categorized as "Activity Specific Sprints" where activities happen in sequence and a hand off takes place after one activity finished so that the team can move on to the next activity, with no overlap taking place during this whole process.

Lastly, another way of implementing Start to Finish is by making User Stories which just deal with one activity like just Coding, or just Testing. All these approaches should be avoided as much as possible if your goal is to be agile.

So how can we avoid this?

An agile way of going about this is taking a finish to finish approach. What would be more important is not when tasks or activities start but when they finish. So coding cannot finish until analysis finishes, and testing cannot finish until coding finishes and so on. In this approach the team overlaps activities and swarms through the stories cross functional rather than taking 'hand off' approach. This is known as a Finish to Finish approach.

Teams that take the Finish to finish approach correctly are able to see how to overlap some activities and create finish to finish relationships between them. Teams find ways to overlap discussions of what User requirements and Coding, and thye also find ways to overlap programming and testing. So how do they do this? By lending themselves to iterative and incremental approaches while dealing with activities. For eg. We do a white board and analysis session, and overlap it with initial testing by creating a test plan, we overlap design and analysis by creating some quick mocks, we check with users if they like it, then we code a little to make features work a little, and test just what is built, then we do an initial UAT, then we code and design some more and finalize the product by finally testing everything.

A quote by Mike Cohn which I strongly stand by 'User experience design, database design, and architecture are often cited as work that needs to be done up front because the work must be viewed holistically. I argue that we should think holistically but work iteratively toward solutions. All sprint activities can and should overlap.'

Reference: Mike Cohn from mountaingoatsoftware.com

The 3 S's of Agile

The 3 S's of Agile

While Sprinting the Scrum Teams might run into issues that a Scrum Master may not be able to control directly or identify easily. He or she may have to do some coaching in order to make sure those issues do not happen. The issue I am talking about is miniwaterfall.

Miniwaterfall is a tricky issue. I say that because it often disguises itself to look like a performance issue on the part of a Scrum Team member. A Scrum Team member who does not understand feature driven development and Agile principles will often fall prey to this issue. It may also happen if a Scrum Team Member does not understand what "Done" is, and why the PO has broken down work into User Stories, and why are they included in Sprints. If crossfunctionality is not practiced proactively it often leads to miniwaterfall. I have faced this tricky self disguising issue so many times that I have come up with a simple solution to tackling it.

We just have to remember the 3 S's of Agile.

Scope - As a general rule Know or determine the Done Criteria of a Sprint, User Story, Task before starting any tasks in a Sprint.

Sequence - Understand the sequence of User Stories and Tasks to help build internal timelines for User Stories and work by those timelines.

Sign off - Sign off (UAT with PO) early even when the feature is buggy, to clarify understanding on Scope and Sequence and any change in requirements.

I can't tell you how many times I have seen team members completely misunderstand a User Story's scope and build features which were not needed in an iteration. This also may happen if the sequence of work lined up in a Sprint is not completely understood. A simple UAT or PO sign off meeting can clarify scope and sequence and save tons of headaches for Developers and Designers!! If you know the 3 S's you will truly be working smart. So please please please, remember the 3 S's. Why work hard when you can work smart?

Why Agile Release Planning Rocks?

Why Agile Release Planning Rocks?

The answer is simple - it takes 15 - 20% of the time a traditional Release Plan would take to be formed by a waterfall company. What that translates to is saving a huge load of money by using the appropriate resources in a common sense sort of way and using their time efficiently. The secret ingredient is simple - it is just about being more agile and scrummy. You have to be cross functional, collaborative, sensitive to time, use relative sizing estimation, do "just enough information and just in time" requirements gathering, always think from a user perspective - which helps avoiding going into an analysis paralysis product design phase.

We are getting ready to form a new Team and so far things are going great! Forming new Scrum Teams with brand new agile requirements, and with brand new locally based team members sounds really exciting to me, always! This situation in my mind is an awesome opportunity to really do Scrum right and reap tons of productivity out of it.

If you go by the recommended Agile way of doing Agile Release Planning, you would start with figuring out what that virtual product is. That would happen through discussions between the Product Owner, Stakeholders, VPs. This discussion should be time boxed and usually lasts only a few hours. The end result of this could be identifying all the users for this virtual product, and the EPIC stories. Once that initial vision of the product is established you can start conceptualizing who (Team Members) you need to create that product and form the team.

The next step would be involve them in the next stage of the release planning in a sort of break out session style. This session would again last a few hours. If there are multiple virtual products you would organize multiple concurrent break out sessions. During the breakout sessions the PO would explain the EPIC stories to the Team members and also talk about rough release plans or deadlines. The Teams would then work together with the PO and SM to break down the stories into smaller User Stories which build small features. These stories would be built on the basis of the Independent-Negotiable-Valuable-Estimable-Small-Testable (INVEST) principle. The SM will play a huge role of making sure this is done in an Agile way. There would be a lot of collaboration between the Team and the PO during this process. We should not be going too much in the "how" to do this phase just yet. Just enough information should be captured and written in (preferably) User Story format. This may be called a pre design phase which is time boxed. Moving away from the traditional way, what could be done is the user stories could be placed in swim lanes which have a high level category - for example "Core Feature 1", "Core Feature 2", "Advertising", "Technical". Each lanes could have their own Epics and the smaller stories could be placed in their respective lanes where they belong. This way you have a clear understanding of where the Story originated from. At first this method might not seem agile, but realistically this method makes it easy for a the PO and the Team to wrap their head around a brand new product, rather than just think of the product as one slice of shippable feature. I say this because most of the infrastructure might not be in place, and there might be some small amount of prep work that might need to be done, hence the "Technical" EPIC lane and so on.

The next stage would involve the PO and the team working out the flow and sequence of all the work to be done. The POs decision will be final on this, although the Team could share their input at all times during this phase, which I think is very useful. Any issues and impediments should be identified at this stage, like need for more resources, or making sure the environments for development and integration are available etc. The release dates will be set during the first stage of this Release Planning. The icing on the cake to this stage would be the Team going ahead and quickly giving each story Story points (eg. Fibonacci). This will help the team break down equal amount of stories for each Sprint and it will also give the PO added advantage of knowing the metrics before even starting the Sprint. Off course, a guess would have to be made on the Teams velocity for the first Sprint.

The last stage would be the Engineering Managers, Architects, POs and SMs getting together and working on resolving any impediments that were identified during this whole day of Release Planning.

Considering the fact that a Release Plan is usually complete within a days time, for a 3 - 6 month project is amazing and very agile. If you add concurrency to this then you get even better results!

Pair Programming

This Sprint we added 'doing more Pair Programming' as one of Sprint Goals. We found out through inspection and adaption that we can reap the most benefits out of pair programming when we tackle new feature chunky stories in themed Sprints.

Stuart Wray from Royal School of Signals published an excellent paper on Pair programming. I think every agile programmer should read it and practice the suggested mechanisms.

In this paper Stuart talks about how to make pair programming more effective. He starts of by talking about defining it - 'As a dictionary definition, I’d say that pair

programming is a technique in which two people

sit down, literally side by side, and write a program at the same computer'. Many people have different understandings of pair programming, and that kind of clarifies any misconceptions before getting into the details of it. He mentions four mechanisms and their benefits. They are Pair programming chat, pair programmers noticing more details, fighting poor practices using pair programming and sharing and judging expertise.

What we do where I work is that we use it for pretty much any kind of work. Managers, testers, designers and developers all pair up functionally and cross functionally to enhance productivity and quality at the same time.

For a feature, the team swarms a lot and does a huddle whiteboard session and extracts any unclear requirements, makes suggestions to PO, and comes up with an OO design. During this time, the team member with the most testing experience creates a test plan and the Team agrees to coding that test plan to avoid scope creeping.

Developers so far noticed that they were making better architectural choices while pairing and are optimistic about it. I personally believe they are actually going faster than they would normally go if they coded on their own. Also it creates an atmosphere of collective responsibility of the code base.

One thing which is crucial is doing it in the right way. A few important things to check for are

1. Are we using one keyboard and one primary computer while paring?
2. Are we switching the navigator, driver roles periodically during a pairing session.
3. Before starting on a pairing task, are both developers clear about the goal of the task.
4. Before starting on a pairing task, are both developers clear about the scope of the task.
5. Is one developer (preferably the navigator) checking on the scope. (time boxing)

It will be interesting to see how fast the work goes this Sprint.

Awesome things can happen while following Agile!

"Well at first you will be blasted with...er...nothing, if you work in an RUP environment off course"

In the past I worked for a company which mainly followed RUP. We were a small Scrum organisation of about 50 people in a large top notch RUP organization. The whole RUP process mixed up with budgeting schedules and bureaucracy can turn into something pretty challenging for a small Scrum Team. Everything moves really slow, until top down command gives a corporate Go decision!

I was playing the Scrum Master role and had a ridiculously hard deadline. We had around 400 hours of estimated work and around 10 days with 3 - 4 resources! These estimates were by no means conservative. There was truly a lot of work to be done!

I had a meeting with a few stakeholders before getting this project started. I remember them saying - "We'll probably get half of the work done based on the estimates, so do your best". Deep down inside I knew that was BS, I knew all of it could be completed :)

First thing I did was met with the PO, did some Agile Release Planning and gathered some user stories and prioritized them. After the priority was clear, I wrote down user stories with the PO, and broke them down into smaller chunks with the Team and estimated them in Fibonacci series complexity points. We used ScrumWorks by Danube, to store all our User Stories and track our Sprints.

Next I did the Sprint Planning with the Team and committed to a bunch of stories for a 1 week sprint. We planned for around 1 hour which is appropriate for a 1 week Sprint. I knew that we literally had 10 working weekdays to get all this work done. I had no idea "How" we would get it done in 10 days days but had a huge amount of hope that using Agile practices like pair programming and smart programming techniques we could speed up productivity.

We started the work with 3 developers. 2 developers paired up on one huge feature and the other focussed on the lower priority features. As the developers paired up they realized that if they designed the system so that it could be reusable, they could save a whole lot of time. Although pairing up took 2 resources' time everyday, within 2 days they came up with a working app with a framework which could be re sued by the other developer working on the lower priority stories.

Thanks to code res-usability, swarming, pairing up and collaboration we realized that our estimated work could be completed in 1/4 of the time. Along with constant collaboration with the PO, we came up with a working app within around 7 days with some extra effort put during the weekend to avoid any disasters.

This over all experience was extremely rewarding and it taught us a simple thing, that "awesome things can happen while being agile".

Observations:

Customer commitment and collaboration was key. A PO ( who was also a SME) was necessary for this to be successful.

Knowing the priority of the Backlog was probably the most important thing in terms of heading in the right direction.

Pairing up helped in sharing of source code knowledge of utility classes and methods written by respective developers. Pairing up helped the developers come up with a reusable solution together sooner than if they had work on this alone.

Managerial support helped as lot. Obstacles were identified as soon as they seemed to appear. For eg. a dependency on the test data generation team was identified earlier on, and a commitment was asked for from them beforehand.

Face to face communication and collocation saved a atleast a weeks worth of time.

Scrum Retrospectives

Retrospectives:

Very recently I have been working with this awesome Sports media company and we are in Sprint 3 now with one of the core product teams. I try and keep things different every Retrospective so that things don't get boring and uncreative. In the first retro I used the 'Mad, Sad, Glad' method of extracting data as suggested in the 'Agile Retrospectives' book. In the next one I used the High and Low points dots method mixed up with the timeline method. In this Sprint I used the Story format which really suits us because most of our work is editorial stuff.
To be honest before trying this I had my doubts. I had read about this technique a couple of years a go but did not have the courage to try it. Maybe it was the corporate environments? I don't want to blame anyone else but me, although corporate environments suck big time.
It started off as a suggestion from me to the team about using this technique. I said "Once upon a time, there was a a Team called Panthor" and the rest was (truly) history. Thanks to the awesome Product Owner and the Team members who helped make it a big success.

Observations:

The Team members felt loose and the story format kind of broke the ice immediately.

An excellent writer and "notes grasper" was definitely needed to make this a success.

What helped is focusing on the good things first and then moving to the bad things.

This method broke the ice and team members were open about talking about things that they normally might not have spoken about in a formal environment, but what was even more important was getting detail oriented and figuring out what exactly went wrong. A few team members took lead on that and it helped a lot.

After all the discussions were close to be concluded, I made sure that we documented a solution to the identified issue.

All these suggested solutions became our Sprint Goals for the next Sprint, which created a positive atmosphere and motivated the Team to move up one level.