Porters! Presort!

Most of the applications I write are data-centric. People put data IN, the application manipulates the data in some way, and people take data out. Nine times out of ten, the data is taken out by putting it into some readable format.  I like to call that readable format a report; oh, wait, so do 100,000 other developers. Nothing new there, but the 100k number is greatly reduced when those developers are asked if they actually like to CREATE a report.

For the most part, creating reports is not glamorous. Creating reports (much of the time) is not very challenging. Let’s face it, creating reports is quite boring. However, just as I would like you to look at the title of this blog in a different way, looking at reports from a different perspective may allow you to gain respect for this much, maligned aspect of application development. So, looking at the title from a different perspective… you might see… Reports!  Reports!

Many senior developers just pass off the task of creating the reports to the junior developers.  If that is your M.O., so be it. At the very least, I am suggesting that you take on the additional responsibility to review all of the reports that are produced from within your various applications. Here are a few reasons why.

1. Quite often the person who ends up reading the report is the same person that approves the check that is given to you for your services. i.e Middle to upper management. The “grunts” enter the data, the application processes it, and the data flows uphill to management. It is often the case that management bases the success of the application development process on the physical output – namely the reports they read.

2. If those reports are clear and concise this is a good thing. If they are easy to read and understand, this is even better. Even nicer is the fact that columns line up, fonts match, data is accurate. In other words, it gives the management-type a “warm and fuzzy” feeling in their tum-tums.  That is definitely a good thing.

3. A group of reports that are “standardized” is a factor in making the overall application appear to be professional. Using similar formats for cover sheets, using similar (if not identical) fonts, and standard headers and footers go a long way in allowing the reader to interpret the report. Much like following a standardized menu design that is similar to other menus in Windows-based applications, a standardized set of reporting design features enhances the overall application.

Give the design and format of your reports the same care you give your code and it will pay dividends. Give reports the respect they deserve. You will be glad you did.

Why use Tasks?

As we coach software development teams in Kansas City, we are often asked about the process of breaking User Stories down into development tasks (anything related to implementing and verify a User Story). This is one of the areas teams struggle with when adopting an Agile process. It's actually something they often struggle with using most any process but most Agile approaches rely heavily on it for a number of reasons.

1) Iteration Planning

Tasks are a good last check for iteration planning purposes. Even though we can rely (to some extent) on past  actual velocity to get a sense of what a team might be able to achieve in subsequent iterations, breaking stories down into development tasks/hours allows the team to leverage what they've learned so far during a given release in terms of some stories being potentially larger or smaller than previously thought. They can use that information to develop a better, more reliable/realistic iteration plan.

During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the stories selected for the iteration. During that discussion they can help each other clarify and improve their development plan and discuss lesser known areas of the code, database, etc. to help other team members learn and become more productive in their development.

2) Iteration Burndown (what's left <how many hours> to do within a given iteration)

Having tasks with hours estimates enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a story was initially discussed, why some tasks weren't ultimately needed. With this information, it becomes apparent that at times, developers may be struggling with a given task and may need help.

It also enforces thinking more thoroughly about tasks needed to complete a story and aides in becoming better at tasking and task estimating during subsequent iteration planning meetings. It also allows the team to get an earlier sense of whether the goals and story points planned for a given iteration will be achieved and allows the team to consider adjustments sooner.

3) Accountability

Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating. It can encourage team members to seek assistance on tasks they might be struggling with as their 2-hour task still isn't done after a couple of days effort while the teams velocity begins to become negatively impacted.

Developing for a story without tasks can lead to stories that don't get done or done as hoped. Without tasks, the team loses the ability to provide assistance (since nobody knows what you're doing) and overall iteration and ultimately release predictability suffers.

4) Shared and Individual Learning

Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all stories and helps them to become better definers and estimators of tasks.

5) Tasking Encourages Better Design

Thinking through a plan of attack for implementing user stories and creating steps (a.k.a tasks) to achieve it tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete story implemenation.

6) Forecasting Velocity

When you don't have the luxury of running an iteration to get an actual velocity but need to provide stakeholders with some sense of cost and schedule, you need to forecast the teams velocity. Using tasks is very effective for this. Do this by estimating team capacity, breaking stories down into tasks/hours until the capacity is filled and adding up the points for the stories you just tasked. You now have a forecasted velocity to provide a preliminary forecast of cost and schedule.

7) Tasks Serve as Reminders

When you task, typically at the beginning of an iteration (during the planning meeting), you have the users  attention and are able to ask questions to which you'll need answers to enable you to think about your plan of attack for a given story in terms of development tasks that will be necessary. Even a few days into the actual iteration, you'll forget at least part of what you discussed with the user if you don't have recorded tasks and you'll have potentially less access to the user to confirm/reconfirm tasks and/or stories.

8) Talk to the Dog

Having to talk out loud and/or in a public setting about tasks you'd need to complete a user story tends to create greater focus than just beginning to code. It typically creates better overall productivity and thoughtfulness in approaching the implementation of a story.

9) What if you hear, "I can't/won't task."?

If a team or team member simply says they won't task, that's more of a personal discussion. Obviously asking them why they won't task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.

When a team or team member claims they can't task you have more information to work with. A common stated reason is that they "just have to start coding" and don't really know about the tasks until they start working on it. One approach is to say "Fine, then write down the tasks as you uncover them during coding and we'll discuss and learn from those to make you a better up-front tasker.". You can also allow a "research" task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.

Above are just a few broad reasons why tasking is useful for software development, in particular for Agile processes.

Agile Development Presentation

Please join Martin Olson for a presentation on Agile Development.  The presentation will be on June 26, 2007 at Visionpace in Independence, MO.  It will be from 11:30-1:00.

Explore how agile software development can improve your bottom line with just-in-time delivery of "clean code that works". Learn why the mantras "inspect and adapt" and "release early and often" have led to a revolution in system development and delivery.

Martin Olson is a Project Manager at Visionpace with over fifteen years of industry experience. Martin has been working with agile development and the Visionpace team for five years. As a Certified Scrum Master, Martin assists Visionpace's clients in defining and steering their projects to a successful completion.

To reserve your seat for this FREE LUNCHEON and presentation, Please contact Kelly at 816-350-7900 to RSVP no later than June 22.  See you there!!