Archive

Posts Tagged ‘development process’

Faster. Faster. Faster.

January 5th, 2012 10 comments

I’ve been thinking about  the influences that might affect the team’s velocity recently. Every single product owner wants to have features delivered as soon as possible. It may seem that this race for a better velocity is the wrong goal and can lead to the ugly “Work faster, basterds!” solution. But that’s not the case in a good and healthy environment .

Here is the diagram I’ve sketched in half an hour to generate some ideas. Bubbles are activities, practices and other entities that can make an impact on the development speed. They can have either positive or negative effect. For example, it seems that only two things improve velocity directly: fast feedback and experienced developers. While there are many other things that slow us down, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt.

Velocity diagram. What influences velocity?

The cool thing about this diagram is that it asks very specific questions:

  • How to deal with customer requests and reduce unplanned work?
  • What to do with urgent bugs?
  • How to do more training?
  • How to have smaller batches?
  • What to do about noise and interruptions?

When you ask such questions on a retrospective meeting, you can expect quite many good ideas. If you just ask:  “How can we work faster?”,  the answer would be silence and confusion.

Visual Builds Board

July 14th, 2011 11 comments

At TargetProcess we develop by feature. This means that all the user stories and bugs have multiple branches. We maintain quite many builds, as branches should be tested one by one. Visual Builds Board shows statuses for all the builds. This simple .NET application retrieves data from Jenkins and TargetProcess and makes it visual.

See the screen below. Passed builds are green, orange builds are running now, failed builds are red.

Builds Board

The board shows where exactly the build is failing. For this one, it’s Unit Tests:

Failed build

The build below is in progress and 3 phases have already passed. Functional tests are running now:

Build in progress

Here’s a full build history for a particular branch:

Build History

That’s how it looks live:

Builds Board TV

The Visual Builds Board has been created by @AlexSane, @eugenekha and @AlexTsayun

Visual Roadmap

May 31st, 2011 5 comments

2 weeks ago we made a large roadmap poster out of four A2 sheets of paper and put it up on the wall in a highly popular place, that is kitchen. The poster shows 2 years in a row:

You can see  initiatives (or epics) rows. Red line is for an epic start date, green line marks release date. Yellow lines show previous and future expectations about releases, but since we are not estimating stories, these are just expectations. Blue line indicates beta-release. Stories and features are represented by yellow sticky notes inside each initiative. The current day is marked by a thread with a marker attached (yes, we utilize gravity force). Future initiatives are marked with large orange sticky notes.

Here is a quick overview of 2010. We completed only 2 major epics and started 3 more that are still in progress.

Currently we are working on Plugins (this epic  has been in production for almost 9 months already) and new Views (the current “in progress” time is 6 months). As you see, we expected to release new Views in April initially, but full JS architecture redesign changed the plans. Quick Add UX activities will be started soon.

Finally, an overview photo:

Development Practice: Design Ideas Board

May 16th, 2011 3 comments

Feedback cycles are very important in software development process. To create cool products we need to get feedback as early as possible, and we need this feedback fast. Design Ideas Board is an interesting way to collect feedback from co-workers on design and UI decisions.

How it works? Mount a large cork board in a busy office location with good people traffic. Anyone can pin a design, a wireframe or anything like that. Then anyone can use sticky notes to provide feedback (make sure that marker and sticky notes are available right there).


Here are some examples: a new web site product page design idea with several critical notes:

A view area redesign sketch with ideas on tags improvements:

Here’s the full view of  our Design Ideas Board:

Why is this board so good? It works as a live information radiator, improving design WIP visibility and fostering team collaboration.

Our Development Process: 1.5 Years Later

April 25th, 2011 15 comments
1.5 years ago I wrote a post that described our development process. It is interesting to see what’s changed. 

Legend:

  1. Survived
  2. Removed
  3. Added

Context

  • Product development (quite large web application)
  • Two development teams: Core and Integration Several Mini-teams.
  • Quite mature product: 46 years
  • Technology: C#, ASP.NET We are moving to full Javascript front end, ExtJS jQuery, NHibernate, ESB

Process

  • Development team has all the power to try new practices, keep working practices and remove bad practices. There’s a little no push from Scrum Master side.
  • We form mini-teams for every Epic. A mini-team includes 2-3 developers, tester and designer (half-time). It is fully responsible for Epic implementation. Usually mini-teams live for several months.
  • We do not use iterations.
  • We do use releases, but often it is just a set of all the features implemented last month. We do not plan releases.
  • We do not have iteration planning meeting, but discuss every user story JIT before implementation on a meeting with PO + Testers + Developers.
  • We do not estimate stories and bugs, just a very brief estimate like (“oh, this will be a large story, let’s split it”).
  • We split stories, but sometimes not as aggressively as required. It is still our weak side. Sometimes user stories are too big.
  • We release new builds weekly (sometimes 2 builds per week). The goal is to release every day, but we do not have a good automated functional tests coverage so far. Automated tests have been improved significantly over the last 18 months. We’ve migrated to Jenkins recently and parallelize tests aggressively. Now all the tests run ~40 minutes and test runs on every push.
  • Smoke testing of the build still takes 3 hours (32 testers).
  • We have a limit of 3 user stories or bugs in progress.
  • We have retrospective meetings every 2 weeks. We run JIT meetings instead of retrospectives. We have an Issue Board, limited to 3 items. When the limit is hit, we run a meeting.
  • We sometimes have technical user stories (for example, remove jQuery from application), but that is rare.
  • We use Kanban Board in TargetProcess heavily and have a large screen in development room.
  • We have a flat hierarchy in the company. There are only two layers and no boundaries between the layers. No formalism at all. Also we do not have positions like Senior Developers, Junior Developers, etc. All people are equal (however, there are informal leaders).
  • We track spent/remaining time on tasks and stories.We don’t track time anymore

Development practices

  • We develop each user story or bug in a separate branch. Master is always ready for release (after smoke testing). We use Git.
  • Pair programming for all user stories and complex bug fixes. Sometimes people work alone on smaller/simpler problems. Pair programming is used for complex tasks only.
  • Developers switch pairs every day, even if user story is not completed yet. The goal is to a have fresh look, knowledge spreading and real collective code ownership. We eliminated pair swapping, it appeared to be distracting and annoying for people.
  • Before implementing a story, pairs discuss possible solutions. It is quite formal.
  • TDD. All the new code is covered by unit tests. Situation is worse on JavaScript side, we just started TDD adoption for UI. We have strong JavaScript testing suite now. Also we use BDD as much as possible.
  • We use Cruise Control and have quite many different setups. Smoke builds, release builds, etc. Functional tests run in parallel and it takes 1 hour to run them all. We use Jenkins now and it takes about 40 minutes to have a new build with all the tests completed.
  • Automated functional tests are based on Selenium. We’ve created a framework in C# especially for our application to make tests easier. Tests coverage is not good so far, but we are working on it (there are 2 automation testers in our team).

ToDo

  • We still want to add performance tests into automated builds. We have performance tests running already, but not as a part of new build so far.
  • We want to split user stories better. Much better.
  • We are incorporating User Experience into development process. This is our main goal for the next year. This  includes running a UX community for customers, interactive prototypes for all user stories, usability testing. We are making steady progress here and we have defined our UX process. However, UX injection takes more time than expected. As usual.

5 Reasons Why You Should Stop Estimating User Stories

April 11th, 2011 48 comments

1. You don’t waste time on estimation

Estimation takes time. Even if you do planning poker and use story points, it still takes time. What do you do to improve estimation accuracy? You gather some data, analyze the data and discuss the results. You are spending time on all that. But are you sure that estimates really provide any value? Most likely not. It is a waste. You’d better spend this time doing something important for the product.

2. You shouldn’t explain to higher managers why it took soooo loooooooong

If you don’t have estimates, you can speak without fear and explain things clearly. You can enumerate problems and explain how they were resolved. You can show that you work really hard and take all the necessary actions to release this story as soon as possible with great quality.

If you have estimates, be ready to hear something like “you screwed up, maaan! You had to deliver this feature till the end of the month! What the f%$k is going on?” as an argument. The team put themselves on a weak side immediately and have to care about deadlines more, not about quality or a better solution. Is it something you really need?

3. You don’t give promises that are hard to keep

You are not relying on people’s optimism (which is built in). People are optimists (almost all of them) and inevitably give optimistic estimates. You can use  complex formulas or very simple rules to have better estimates, but is it really worth it? You can spend many hours defining correct formula for exactly this development team. People will not trust you, since you (rightfully) don’t believe in their estimates. Numbers will look “made up” and still you will have incorrect estimates in the end.

4. You don’t put additional pressure on development team

In some teams Estimate is equal to Deadline. That’s bad. What do you do to meet the estimate? Compromise quality? Tolerate average architectural solution? Abandon polishing? All that leads to poor solutions that end users will not like. It is better (almost always) to spend more time, than planned, and release something really usable and useful.

5. You focus on really important things

Imagine, you have a planning poker session and estimate all stories inside an epic. You sum up all the stories and define it as a 1000 pts epic. You just stick a “fear” label on the epic. People do fear large problems. A 1000pt problem is huge and psychologically it is harder to decide “let’s start it right now”. Product Owner will have a temptation to implement 100 smaller user stories instead of this huge epic. However, it may be a bad decision. This epic may be really important, the morst important thing for the product.

If you don’t estimate it and are not completely sure about its size, you have a better chance to actually start doing it.

Development Practice: The Ultimate Clean Up Day

December 3rd, 2010 8 comments

cleanup_day

We are using Kanban for product development. It works great. As a Product Owner I can re-prioritize backlog anytime and put things into Planned state when I want to. It works. But. Every Product Owner is passionate about the product. He wants to improve so many things and do that RIGHT NOW. Prioritization is really hard and Planned state has a strong tendency for saturation and overflow. For example, our Planned state has limit of 20 items. In the worst case there were 50 items in it (most of them are bugs and small enhancements). Mea Culpa.

The obvious side effect is that most items are buried in Planned state for weeks.  A more important user story pops out and a small enhancement moves down. As a result, enhancements and bugs were never fixed/implemented. Planned column turned into Backlog column someday. That was a real problem. Yes, bugs were small and quite easy to fix, but more important problems constantly pushed them back.

We got tired of this and decided to try a new practice: The Ultimate Clean Up Day. The rules are quite simple:

  1. From the start of the workday everybody who can do programming (including CEO :) take any bug/small story from Planned state and fix it. Repeat till the end of the day.
  2. Someone suggested to draw a star on the whiteboard for each fixed bug and find out who is the best bug fixer.
  3. Testers verify fixed bugs as soon as possible and cooperate with developers to ensure the fix. Repeat till the end of the day.

We were afraid that the clean up day will take longer than 1 day due to re-opened bugs and so on, but this did not happen. It was a very focused activity resulting in 23 fixed bugs in a single day. It was fun and development team decided to do this monthly. Next clean up day will be in the middle of December and I will re-fresh my .NET skills again :)

Product Backlog: Small Steps vs. Giant Leaps

April 29th, 2010 7 comments

When reading this Kill Your To-Do List blog post, I thought that managing personal to-do list can be similar to product backlog management. Not in the part that you should totally kill your product backlog, but in the “one thing at a time” part. This is by no means a new thought.  E.g.  Mary Poppendieck was heard saying that product backlog should be eliminated.

So, as in to-do lists, there’s no point in nurturing and moving product backlog items back and forth.  In this case, a lot depends on what is your definition and understanding of product backlog. I’d say backlog is an environment in which a product grows and exists but not a set of components that should be implemented for sure.  Looking further into, what kind of environment is it? Backlog might be a repository of all the slightest shades of ideas that have a very vague chance to be implemented. A chaotic heap. This heap can hardly be called a “backlog” but rather a by-product of brainstorming. OR a product backlog might represent a careful selection of user stories that will be implemented for sure.

Both of these options, as often is the case, have the optimal state somewhere in between. In our production workflow, we’re now using several buffers – the first layer is raw Requests and Ideas (coming from our HelpDesk, or from the PO, or from the team). The second layer is Product Backlog with User Stories (Requests and Ideas are now groomed and converted to User Stories by  Product Owner who decides that some time these will be implemented for sure – based on how many people requested this feature, based on current product development strategy etc.). The third layer is Planned state for User Stories in Kanban board.

Here’s a quick graphical representation of this product backlog upward funnel:
maslow
That’s how User Stories lifecycle looks on  Kanban board, from Planned state on:

kanban-board-and-on

Backlog is not seen on Kanban board.  When done with their current user stories, developers  pull new user stories from Planned state.

Previously, when we worked with iterations before switching to Kanban, there was no buffer between inception and implementation – so time-boxed releases and iterations have been planned directly from the backlog. With Kanban, the buffering  is done by moving stories to Planned state and prioritizing them.

I’d say that planning with iterations provides less flexibility than planning with Kanban. As you drop user stories to time-boxed iterations, you  commit to implementing all of them within a given period of time. Kanban is way more flexible since user stories can be pulled one-by-one from Planned state and implemented with no time restrictions. I can’t resist citing an analogy here: it’s the same as moving with the smallest possible steps to posture yourself before hitting the ball in tennis. With large steps, you do not have flexibility. With small steps – you’re very agile and flexible to position yourself for the perfect shot.

So, the buffered Planned state in Kanban is like this breaking down into small steps, instead of taking one giant leap and committing to the whole pack of user stories in iteration.

That’s the way it goes for us. You’re better off moving by small steps, taking it one-by-one (this brings us back to the inspiration blog post reference in the beginning :) than with giant leaps.

Agile Outsourcing: Get It or Forget It?

January 26th, 2010 21 comments

Bringing together agile philosophy and software development outsourcing has been one of the hottest topics over the last decade.  Lots of blog posts, discussions in social networks — people try to figure out for themselves if it’s at all possible to align agile methodology with the existing reality of outsourced projects.

How can vendors who practice agile gain new customers? How can customers as newly-converted adepts paste their vision of agile thinking on their existing outsourcing partners?

First of all, let’s look back into when and why actually did it all start with IT outsourcing. Manufacturing outsourcing existed since long ago, but IT offshoring only started at the end of 80′s – beginning of 90′s. Companies jumped at the opportunity to save bucks and use cheap labor not only for producing goods, but for producing software. So, the main point is that from the very beginning outsourcing has all been about saving money. No other notable motivation – just saving money and using cheaper labor.

homework

Next, along comes agile manifesto. People start seeing that the waterfall approach  they’ve been using with their outsourcing vendors is not that good after all.  Fixed price contracts do not guarantee real value (Scott Ambler writes very well on that in this article). Next, the more labor is outsourced to some country, the higher are the costs, so the main point for outsourcing which is cost savings makes no sense any more.

There’re other even deeper-lying consequences. On the one hand, the country which outsources – or businesses in this country not the country itself – they save bucks but lose in the long run as they do not grow their own engineering minds, let alone all the problems that you have working with remote teams – yes, we have all this telecom in place, but nothing ever will replace face-to-face communication. If you often go on business trips to the outsourced destination to talk to your team – again, it’s more costs.  On the other hand, outsourcing makes a dangerous long-term impact on the recipient economies as well.

But the point is not about how bad or good outsourcing is.  Vendors have written an array of blog posts on how to align agile and outsourcing – and that’s natural – they want to keep going, so they do everything to back up their point of view proving that agile goes well with outsourcing. This might work true in some cases.

The companies that outsource on the other hand – they have legacy outsourcing teams. They need to get going with them as well, to stand up to all the funds already invested in their outsourcing center/provider.

So with all this outsourcing in our hands – what do we do?

As an agile outsourcing vendor, you should be ready to invest lots of time and effort to educating your new customers on the value of agile and to building a solid relationship. This might be a very difficult task since some people just don’t want to get educated and prefer to stick to good old fixed price bids, logging and billing for gazillion of change requests, lack of communication and other “joys” of classical outsourced development.

As a company with established outsourcing facility, you’re better off. But perhaps you could be even better off if you started this relationship not with an overseas company, but with a guy next door at least.

Anyway,  you are where you are – so you would need to work with your outsourcing partner to practice the agile approach, since at the end of it all work with agile methodology brings real value, as opposed to counting short-term waterfall pennies and losing long-term gain.

TargetProcess TOP 10 posts in 2009

January 14th, 2010 No comments

January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back  and recall the most interesting blog posts by TargetProcess in 2009 :)

dedmoroz-prozra4en-746252

Based on visitors count, the posts are ranked as follows (descending order):

1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.

2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying  to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)

3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.

4. Tale: Deadline and Technical Debt: Once upon a time…  Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go:  smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.

5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong”  instead of  “what’s right” …

6. How We Use Kanban Board. The Real Example:  Once we figured that Kanban process is just the right thing for us and put it in action, we shared this  experience with our blog readers.

7. 5 Right Reasons to Apply Kanban: There they are :)

8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.

9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.

10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.

These are the TOP 10 posts  in 2009 from TargetProcess agile blog (click here for more)

Happy OLD NEW YEAR! :)