Category Archives: kanban

Jira vs Post-It Notes

Had some recent discussions on the subject of using tools or just sticky notes…

for me, a digital board representation of the kanban style 3-column view is merely one v-e-r-y small aspect of using something like jira.

though i could probably live with just post-it notes, i bet it would be an interesting challenge for me. i have been:

  1. doing only distributed work for so long (since late 90s)
  2. using jira so long, it is as simple as a pen and paper (or post-its)
  3. dissatisfied trying to do a project with something simpler like Basecamp, without the richness of jira
  4. working on long-term projects that have different people rolling through, and years of life (4000+ issues)

and i ask myself what other benefits do i derive from jira (plus, admittedly, a companion wiki)? why might i be uncomfortable with just post-its?  do i have an unnecessary “crutch” in the form of jira? hmmm… do i do more than is necessary in the way of using jira/wiki to add other pertinent documentation for the project?

well, here are the following things i can think of off the top of my head:

  • it is easy to
    • assign myself to an issue
    • move it to be in progress
    • move it to be resolved
  • our virtual chats hover around the greenhopper view
    • we’ll edit stuff on the fly as needed
    • quickly create a new issue if something pops up during the call
    • everybody refreshes their browser
  • we put a fair amount of supporting docs — details, helpful things — into the issue (or into the wiki and then that link goes in the issue)
    • that way you always know where to look 🙂
    • you can find it 24×7 and regardless of your GeoLoc
    • sometimes we’ll have skype chats and voice calls about the issue, maybe about design ideas. I’ll shove those things into the issue.
  • we can link related issues
  • we can use the search to look up old issues and refresh ourselves on what was asked for/done
  • we can have asynchronous, threaded conversations in the form of comments
  • we can track any myriad of other stuff against the issue
  • i log my hours against the issue
    • useful for billing if you need it…
  • i can use it to help generate pretty charts for management
  • we use the issue status to trigger QA (in addition to our chats)
  • i use jira to help ensure product version notes are up to date
    • jira manages the iterations
  • pretty easy to maintain a backlog, even chunking it up into groups if needed
  • easy to indicate that an issue has been rejected, and why

the point is, i find it incredibly useful to have modern technology at my fingertips…

in my experience, there is so much more to a project tracking “tool” than what post-it notes would seem to represent.

[important]but i have NO (zero, nada, zilch) experience being part of a co-located team using post-it notes. so take it with a grain of salt :-)[/important]

Considering Sprint Length

A friend of mine had an interesting situation:

  • Novel product, many unknowns
  • Multiple teams grouped into 3 product areas
  • Experience doing 3-week sprints

Only a fool would do anything other than the 30-day official sprint cycle that I saw on some website and in a few books.

(Just kidding. Unfortunately, like most of agile development, context has a tremendous impact on what you choose to do, process-wise.)

A lot could go into what the Optimal Sprint Length should be… You could ponder the dependent variables and try and guess an optimal length to optimize the independent variable(s) — which would be, what, maybe cost and rate of feature delivery and quality? You could do the “democratic process” and allow the team to vote, or even do “rock-paper-scissors” to figure out 2 or 3 weeks.

However, what if we built a continuum of sprint lengths for the sake of discussion. On the one end, we start at the idealization of doing one useful feature at a time and deploying it immediately — think simple web app. Anything longer than this is a compromise based on some (hopefully valid) reason. On the other extreme, we could wait until the entire system is done before deploying or integrating, maybe after 6 months or a year.

The cost of “batching up” the “work in process” at the upper end of long sprint lengths, is pretty obvious to everyone. I submit, that if you agree with (or experience first-hand) the premise that batching work has a non-linear impact on overall cost (including the hidden and subtle cost of everything that we know is bad with waterfall), then it stands to reason one might favor shorter cycles and less batching.

Not to digress, but the parallels exist in industry. To allow WIP to be large, and to allow certain parts of the process to run at high levels of batching, is a risk. A risk that the items in the batch, once released into the wild, are discovered to not be as valuable as first thought. Well, it’s water over the dam, time and effort you will never get back. (Think: extra features built because someone thought they would be useful, and it turned out that the marketplace thought otherwise.) Nonetheless, sometimes weighing the risks will lead you to some level of batch that makes the most sense.

There is often much more to the decision on sprint length than purely the development team. For example, what is the cost of QA? If the cost of QA is no different for 1 feature at a time versus a week’s worth of features, than QA cycle time/cost is not an issue. However, if it requires a week of QA time to regression test the system in the case of even a single small feature or bug fix, then you have a serious input into what the optimal sprint length should be.

Naturally, one could do development sprints at one frequency, and QA sprints at another… and even customer ship sprints at a completely other cycle time.

Regarding multiple teams… this is a solution that can be recursively applied, much like you would at a software architectural level. If the teams are horribly coupled, your costs will balloon and no amount of pondering sprint lengths will have a significant impact. If the work dependencies are carefully controlled between the teams, sprint length could vary between teams due to their own local reasons.

Much like the QA process can be a “tax” on each Sprint, what other taxes does your process incur? Running down to a one week sprint will likely reveal expensive parts of the process that could be ripe for improving.

So having said all of that… Here’s a thought. Why not simply agree to try out a few different lengths for enough sprints to get a feel for the differences. Try one week sprints for the next 6 weeks. Try 3 week Sprints three times. See if you can monitor metrics that will tell you what worked better. Consider that different teams might also work at different frequencies to test the “costs” of thinking the teams should be synchronized.

Much like with our USA republic, surely don’t let democratic, mob rule win the day.

Plan & Estimate, Only if You Must

It must have been the morning to challenge planning efforts, as GeePawHill did here. I was answering a post that had gotten around to discussing budgeting and planning for interruptions to fix legacy apps while teams are building new stuff.

When all of the sudden, I blurted this out:

Kanban is simple, in theory. Simply do one feature or bug fix all the way to being released. AKA focus. But there is a lot of things that have to be working well, for example: the cost of testing has to be low so that it doesn’t cost a fortune in treasure or time to get in that new feature or bug fix. (Expensive testing often leads to bundling a bunch of stuff into a given release and widening the time window, and introducing parallel development techniques.)

And, regarding budgeting in to prepare for the unknown maintenance efforts… That’s but one way to handle things. Another way is simply let the people who care about getting things done participate in setting your priorities. If you were given 10 things to do in a month, and halfway through you get an 11th thing to do. You probably don’t need to budget for that unknown. You simply ask for help deciding which of the original 10 should get axed to make room for the new “emergency” item.

Like it or not, you are all in it together, it is a zero sum game. If you fix the resources, fix the schedule, the amount of work that gets done has to give when new work is injected. Deal with it in an honest manner.

Hard to describe in words… and had to know your exact context… but what you are facing is probably more of an organizational issue than anything else.

All we software folks do for a living is produce features and fix bugs to keep paying customers happy. Just keep trying to improve your team’s efficiencies and squeeze out wasteful practices.

When you are producing software as an internal organization, you can sometimes be brave and forgo lots of planning stuff. If you have the priorities set, and if you have a delivery schedule, and if you understand your costs of releasing, you can make a pretty simple and smooth process. I’ve done it many times in companies formerly steeped in waterfall fantasy land. Why waste all sorts of time making estimates if you don’t have to?

The answers to these questions can help you decide how much ceremony your processes need:

  • Does it matter if the team does 5 things in an iteration or does 10?
  • Does it matter if they estimated 10, but only wound up being able to do 5?
  • Or, if they bid 5 and found they could do more and gobbled up 10, is that a problem?
  • Is it more important to hit a date with at least some features?
  • Or, is it more important to produce specific features as fast as you can, even if you miss the date?
  • Does the team need to be accurate on their estimates? How accurate and why?

Many times, we fall into traps of wanting to manage software process as if it were a brick-making factory. Unless you live or die by doing software as a fixed-bid project, you can often really get simple and make software really fun in your organization by doing less ceremonial planning crap!

Ideas for a Distributed Team

In response to a posting on Agile Project Management…

I am starting up a ‘Distributed’ Agile Project and looking at tools to assist the distributed team communicate the status of work undertaken, stories, estimates and burn down/up charts as well as general collaboration (forums, document sharing etc).
There are tools such as Agile Wall, Mingle, Trac (with plugins etc).
I am ideally looking for an externally hosted solution (something that we will not be setting up in-house).
I have a core team of 15 people and with an additional 10 people that would want access. I am looking for any ideas or suggestions on online tools that you may have.
Thanks in Advance.
Regards
Neal

I’ve been doing this sort of thing since 2000, so it is very easy and very possible to be extremely effective as a distributed team.

Here is a very simple approach using Basecamp (and you can get an add-on for burndowns if you like that sort of thing). I’ve been doing this on a small project since March or so.

Then I set up other simple collaboration tools (looked like this on many projects, though you might have to march around that hodgepodge of a site to find more tool ideas):

  • Wiki: Project stuff that is not issues or code needs a home; a.k.a.,
    (you can use basecamp, though not as extensive as something like confluence)
  • Chat Room for being the virtual cubicle farm and water cooler. Skype or IRC works great. You can establish key words that call out for attention, like “@ALL I’m going to kick the TEST server.” You can even have textual scrums if voice is not always possible. For a while, we had a bot that recorded the chats and logged them to the wiki 🙂
  • Issues/Bugs: You need a place to store your lists of things to get done. Some call that an issue tracker; others, simply a To-Do list. I have used Jira for a l-o-n-g time for both features and bugs. I have also used Lighthouse — which is just fine too.

Atlassian Studio is worth a look. You can add in continuous integration and code reviews and what not.

My suggestion: start really small and humble with the tiniest process.

That really simple Basecamp process I blogged about? We actually got to PRODUCTION with much less ceremony. There were none of the “To be QAd” or “To Be Released” because we did it more in iteration chunks, so we knew the overall state of a given iteration (in dev, qa, or released).

The slightly greater ceremony of QA and Release buckets allowed me to answer the need from the stakeholders and other non-developers to know the state of the project at a glance. It’s easy to see what is in the backlog, or what is in progress, or waiting QA, etc. Now we’re doing Kanban. I crank issues and (rare 🙂 bugs through one at a time usually.

Anyway, have fun!

Using Basecamp in an Agile Manner

Software Development Life Cycle

In software development, we want to make our process as visible as possible to all participants and stakeholders. To that end, behold a simple process that uses a handful of Basecamp To-Do Lists as markers for how a feature or bug is working its way through this process.

At any point in time, you can look at the “To-Do” list page for a status on your favorite new feature, task, or bug. And, if you have a chunk of features piled up in an “Iteration 1” list, you can see the number of items being worked through to completion. (There are even third-party apps that allow you to do burndown charts if they appeal to you.)

Using Basecamp's To-Do List in a simple manner

Requirements/Bugs

The business has a desired priority for features as expressed by the order of items in the “staging” lists, and especially the On-Deck list (to borrow a baseball metaphor for “What’s next”). For major new features, the business and the developers will work out a rough Release Plan. But for simple enhancements and bugs, the business can simply add desired items to the lists.

Development

The Developer will pick a new task off of the top of the On-Deck list. There will usually be a conversation around the issue to ensure proper understanding (unless it is self-explanatory). Ideally, we get the business/testers helping to write User Acceptance Tests in the BDD form of Given… When… Then… The Developer moves this feature into the “In Progress” list. If desired/possible, the user could add a date estimate for the task.

The Developer will create tests, be they Cucumber, RSpec, or UnitTest, or all 3 types. If possible, the Testers can help write the up-front acceptance tests, so that they are intimate with the feature/bug. The Developer writes code until the tests pass.

Once the issue is complete, and the tests are passing (and you didn’t break any other tests), the Developer: commits the code, updates the TEST server, and does a smoke test to ensure things still work as expected. The Developer then moves the task to the “To Be QA’d” list, where the Testers will now verify the issue is indeed complete and correct on TEST. Close collaboration between Tester and Developer is warranted here, as the nature of the fix and any developer tests can be explained so that testing can be as effective as possible. Plus we want to maximize use of automated tests, and minimize any unnecessary manual tests (as they are time consuming and expensive) given the nature of the code changes.

Testing

If the QA passes, the Tester moves the task to the “To Be Released” list. Depending on the nature of the feature, the Business can also help to “test” and ensure things work as expected. If the test fails, then the task is moved back to the On-Deck list and the details added to the issue as comments (if simple) and image uploads (add image link to the comments), or to the issue tracker if it is more complex (even though it is technically not an issue against the released product).

Release

The Developer will schedule the move for “To Be Released” tasks to the PRODuction box. This may require coordination with the client’s IT team if they have internal controls. Following release, the application is smoke tested to be sure the basics are still functioning. If any problems arise, the server can be rolled back, or fixed ASAP, based on the nature of the error.

Once the items are released to PROD, you can indicate that they are “complete.” If the issues came from a list that you want to keep for posterity, simply drag the completed task to the original list (“Iteration 1” for example). Now you can see the items in that list that have been released (i.e., completed).

Summary

I’ve used Jira and much more elaborate SDLC schemes in the past. But a recent Rails project with just a few folks on the team, found us trying out Basecamp. By creating various lists, we can mimic the Kanban-style wall board that Greenhooper provides within Jira. Because the lists allow simple ordering to show priority, and you can drag-and-drop between lists, and you can track your time, I think we have a very lightweight, winning combination.

This process is equally at home doing one feature all the way through, or an entire iteration’s worth of features in a bigger chunk. (Basically dependent on the cost of testing and the appetite of the end-user for changes.)

SDLC process[/caption]