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.