In a month we will run our third internal conference. This is supposed to be a full-day event, with one-of-a-kind sessions prepared and presented by our team members.
Here is the program:
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.
The cool thing about this diagram is that it asks very specific questions:
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.
Almost 2 years ago I published the Flow. Discover Problems and Waste in Kanban post. The idea was quite simple: visualize the flow of a single user story or bug, and track their life cycle to Done:
You can spot such problems like delays and re-work very fast this way:
Now we’ve brought this idea to life. The Flow chart for every user story, bug and feature will be available shortly in TargetProcess v2.22.9.
The chart gives answers to a whole lot of hands-on questions:
Let’s look at some examples. The user story on the chart below has been in Open state for 25 days (it means, in the Backlog). Then it jumped right into In Progress state. Two developers (Alla and Vladimir) started working on it (so it was pair programming). They’d been working for 3 days and then the story was moved into Re-open state. This is quite surprising, most likely they had to switch to something else (no good). Then they got back and spent 15 days working on this user story. That’s way too long. Most likely there were switches as well, so this should be investigated.
Starting from Oct-18 the progress was very good: development went smooth, tester found several bugs and they were fixed in 2-3 days. Finally, the user story was released to production with no more delays.
You immediately get a high-level overview: delays and up/down state transitions. It is a clear sign of some problems, the systematic ones or not known so far, but we already have some background info to start an investigation).
Let’s check another example. It looks like the user story on the chart below was taken to development right as it was added. That’s true in fact, since it was a customer request to which we reacted immediately. It was implemented in a single day, and there was a small delay before tester took it to the testing phase. We found quite many bugs and fixed them in 2 days, everything is fine. But then the completed user story was hanging in Release Branch state for 11 days, and that’s no good.
We’re planning to extend this Flow Chart and put more information there (comments, attachments, etc.) The goal is to provide the complete production timeline uncovering hidden malignant patterns and problems. You should be able to get a high-level overview in an instant and dig into as many details as possible.
Here is the snapshot of our real TargetProcess production Kanban Board taken today (November 18). You can see what we are working on right now, what is in progress, what is in testing and what will be released soon.
Software penetrates every pore of human existence. We look up the weather info over the web, giving up on outdoor thermometers. We’re driving to destinations with GPS navigator (forget paper maps with their G7 sections on page 59). We turn on RunKeeper when riding a bike to calculate the average speed and run and boast in Twitter. We’re using software every single day of our lives. It seems we’re hugging our dear gadgets a lot more than our loved ones.
No one knows the exact how-to of writing great software fast, that’s the problem. Waterfall passed away at the crossing of 2 centuries, whereas new software development methodologies (agile) fail at solving the fundamental problems so far. We’re living in very interesting times. Software development industry grows fast right here, right now, and the foundation for a quantitative leap is building up.
Have you ever asked the question, ‘When are we planning to do bug analysis?’ in a Sprint retrospective? This is one of those questions that is thought about but not asked during the initial iterations of Agile projects. Also, unfortunately, this question is forgotten over several subsequent iterations and asked during the end of projects when it becomes too late. By ‘bug analysis’ I mean the analysis of a group of bugs to study factors such as distribution of defects on priority, severity or application module as well as other aspects such as reproducibility or dependencies.
Several years ago, I became cognizant of asking this question. It was never an ideal situation for us to deliver bug free production ready software at the end of iteration. I am sure, even these days delivering production ready software at the end of iteration is not very common across projects. It is a tough goal. If you have achieved this goal, I should say you belong to a high performance team. In all general circumstances, bugs do accumulate, get prioritized, and fixed. Is this an adequate approach to execute projects? Don’t we need to identify the right time to initiate bug analysis and have a consensus on the frequency of performing bug analysis?
The first time when I asked this question the answer was, ‘The product is not stable enough to perform bug analysis.’ That took me by surprise and triggered additional thoughts. I asked further, ‘Should we wait for the product to become stable to do bug analysis? Or should we perform bug analysis in order to find ways to make the product stable? Also, shouldn’t we use visual boards to display bug trends and analysis so that the team understand not only the progress of user stories but also trends on product quality?.’ That’s when our approach matured to the next level.
Essentially, it makes sense to have a sizeable number of bugs to perform bug analysis and it depends on your project. Also, how detailed you perform bug analysis depends on your project as well. Bug analysis can reveal variety of useful information such as distribution of bugs across modules, distribution in terms of bug priority or severity, distribution of bugs in terms of bug status etc., The earlier we analyze and understand these parameters, the better it is for us to improve product quality.
Thinking of bug analysis late in the game seldom yields efficient measures to improve product quality. Next time when you talk to your Agile team try to trigger this question. Am sure you will come across interesting responses.
All said and done, bug analysis is a practice that can yield results in Agile projects. Do you use a visual board that displays bug analysis results and trends in your work area? What has been your experience in performing bug analysis? How frequently you do it? Is it beneficial?
Raja Bavani is Technical Director of MindTree’s Product Engineering Services (PES) group and plays the role of Product Engineering Evangelist and Agile Coach. Check his Product Engineering blog.
How does a great design differ from a good or mediocre design? Often the difference is just in the smallest details. These details shape user experience and greatly affect the way we feel about a product. The product may look great, but people remain cold using it. They don’t feel it is designed for them.
Views functionality in TargetProcess is not a rocket science. There are thousands of applications with views. View is such a boring page to work with usually .
New Views in TargetProcess are crafted with great attention to details. Every single detail is thought out. Every single decision was debated. Let’s dig into details. I will show and explain all of them.
Inline edit (edit-in-place) is a huge thing. It allows you to edit everything very quickly. These two words are important: everything and quickly. In our new View you can indeed edit everything and do that really quick. But this is not all. Watch these two very short videos.
Inline edit in JIRA
Now compare it with inline edit in TargetProcess
The difference is clear. When you are editing something in JIRA, the effort value jumps back and forth. It is somewhat confusing and unpleasant. Effort in TargetProcess stands stone still as you edit it. This produces a totally different feeling. When everything is still you feel that things are under control. The jumps, on the contrary, are quite distracting, and you feel that something is not good (but often can’t say what exactly).
People assignments component has all the small details that make it just awesome. Avatars enable quick recognition. You may think that avatars are not important, but with time you’re so used to them that you identify a person in a split second. Humans recognize image patterns much faster than words. With first and last names only you have to read. With avatars you just scan.
Quick filter is the fastest way to find someone if you have a large development team.
Popular actions are available on the top. Quite often you want to assign work to yourself or un-assign work. It is always a good idea to put popular actions to a visible place.
Moreover, potentially dangerous actions are marked red on mouseover, which secures them from accidental clicks. Also, the red mark builds up quick memory for actions. For Unassign, you will point mouse cursor and click quickly if the button is red without reading.
There are two types of links: some links represent actions and some links are usual links. There should be a clear distinction between the two types of links, thus action links have a different underline style (dotted):
If you can perform an action (like edit), you miss an opportunity to jump to entity. This problem was resolved by adding a tiny icon. The icon is an idiomatic pattern to navigate away from the current page.
When a property is empty, it is not clear if you can edit it or not. You point cursor to an empty row and think something like “Hmm, is it possible to edit something here?” Then you click, and it appears that it is indeed possible to edit this value. But why make people think? The clear message is shown in an empty row when you move mouse over it:
It is a good idea to show only relevant details. For example, you want to change release or iteration. Releases and iterations have end date, you have many releases and iterations that are already done. Most likely you don’t want to assign a user story to an old release. Thus, old releases are hidden by default.
Mouse over pattern is everywhere. So, all actions are hidden by default. You need to move a mouse cursor over a comment to edit or delete it. Thus interface is clean and not burdened with repeated buttons. There is one disadvantage in this approach: available actions are invisible by default for new users, and they might not be actually aware that they can edit something. But we consider this a good trade-off. We don’t design for new users, we mainly design for people who continuously use our product.
How often you do you need to upload several files, one by one? It is intolerable in a modern web application. People should be able to upload all the files at once:
The general layout is pretty straightforward. You have a content area with title, tags, description, attachments and comments on the left, and more details area with miscellaneous information on the right. This separation is logical.
The layout of the area on the right is beautiful. The most important information is on top. For example, status of a user story and its progress. Then you see all assigned people with estimated effort. Everything is lined-up and there are no unclear labels or weird information. Only relevant information is visible. You can also hide information blocks if you want to.
This is it. New views are in beta and more improvements are coming. Stay tuned and give us your feedback. We live by it.
I’m reading books on TRIZ and becoming enthusiastic about its potential for software development industry. Yes, it is not clear how to apply it directly, since TRIZ focuses on technical systems, but I believe we can apply general rules and even have solution patterns in the future.
TRIZ has several patterns of evolution. Here are my thoughts about the most interesting patterns and their applicability to software development.
Every system generates both useful effects and harmful effects and every system has costs.
Ideality = Benefits/(Cost + Harm)
Software system is not an exception. If we take a project management software, it helps us stay on track, plan work and see progress. What is the cost? Well, it takes time to add data into the system. It takes time to find useful information. So the system wastes our time. An Ideal Project Management Software (I use big letters to stress its ideality) will add data from various sources fast and provide all information we need in 2-3 clicks.
The other hidden costs? A learning curve is often significant. Migration to other project management software is not easy and painful. Customization sometimes impossible or very expensive. All that should be (and will be) resolved in the future.
Each new technology follows a S-curve pattern. Slow early adoption, sharp growth with mainstream adoption and finally slow growth to a full saturation.
source: An Introduction to TRIZ
In software development there are plenty of examples. OOP went mainstream years ago and it is not sexy anymore. REST services grows sharply, mobile industry grows sharply, Agile adoption is mainstream now. It is more intresting what is cooking in early adoption phase right now, what will change the future of software development. Is it TRIZ and problem solving techniques? Is it Continuous Delivery? I don’t know, but we’d better keep our eyes wide open and discover trends as early as possible to ride the wave.
“A system encompasses different parts, which will evolve differently, leading to the new contradictions.” Every software system has various parts such as modules, layers and components. If you think about that, you will remember many cases when one part of a system was improved significantly, while other parts of the system stayed as is. Very often this significant improvement leads to new, unexpected innovations and total re-work of existing modules.
Let me provide an example from TargetProcess. We decided to re-write plugins. We were not satisfied with the existing architecture and we were going to find a more efficient approach. We stopped by ServiceBus pattern and implemented the solution. However, then we faced a new problem: how to create UI for new plugins. It was solved via Mashups and it was totally unexpected from the beginning. Now Mashups are a part of TargetProcess and people can do very interesting things via Mashups.
Very often a new module design brings along major changes in system architecture. We decided to re-design Views, and new Javascript architecture evolved (tau js framework). All areas of TargetProcess will be based on this new tau framework as a result. It’s amazing how often this law is actually observed in software development.
That is my favorite maybe. “There is a tendency for systems to add functions that at first increase complexity but over time collapse into simpler systems that provide the same, or more, functionality.” It is so common for a software system to become more complex, to add new features, more features. There is even a term for that, coined years ago: bloatware. This law clearly advises the natural path of evolution, and Simplification phase is crucial. However, usually simplification never happens and software product dies.
source: Featuritis vs. the Happy User Peak
I can clearly see this pattern in TargetProcess as well. Initially it was a pretty simple product with a few features. It grew into a quite complex yet powerful agile project management software with many integrations and customization options. In worst times we had about 100 different screens in the system. Everything could be done differently and somethimes you had to visit several screens to complete a single action .
We started Reduction phase last year. We are re-working all the functionality and we have a clear vision on how to shrink all the complexity into 10 screens or even less. It is really cool to see the way and to follow it. It is fun and you have a genuine feeling of the “right way”. We fearlessly removed features that are almost not used, yes. But interestingly enough, new, fewer screens will provide even more functionality than the old ones.
I believe this is the path all software systems should follow. More complexity, more functionality, then Simplification and Reduction.
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.
The board shows where exactly the build is failing. For this one, it’s Unit Tests:
The build below is in progress and 3 phases have already passed. Functional tests are running now:
Here’s a full build history for a particular branch:
That’s how it looks live:
The Visual Builds Board has been created by @AlexSane, @eugenekha and @AlexTsayun
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:
