Edge of Chaos

Setting out to write a series of articles on agile retrospectives, I looked at some of the sources currently available on the subject. It turned out that most of the books, articles and blog posts have been written by external facilitators or agile coaches, and sometimes in quite a complicated language.  I somehow got an impression that – at least in their writings – they prefer to go with the generic recommendations cut out for hypothetical dummy John Doe teams.

So, I’m not going to list someone else’s how-to’s, telling you to blindly follow the techniques acclaimed as best practices. Instead, I’d like to focus on some heuristic essentials for a team to be self-sufficient with their retrospectives. When the essentials go home, the how-to’s are not a problem, they come effortlessly as your team intuitively knows what to do. That being said, I will still mention some of the techniques, questioning their practical value in a team-specific context.

Heuristic Approach

Heuristic refers to “.. experience-based techniques for problem-solving, learning and discovery. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgement, or common sense” (a quote from Wikipedia). Let me reiterate that “experience-based”  does not refer to the experience of external facilitators, but to the hands-on experience of a team as they try, discover, fail, learn and move forward. Maybe I’m a bit biased, as we’ve never hired an external consultant or facilitator at TargetProcess. It’s always been our own trial-and-error, common sense and intuitive judgement.

I’m a fierce proponent of heuristic approach to anything, agile retrospectives included, as this approach is about what delivers. No facilitator will do the job for a team, if their goal is to facilitate good retrospectives only. This is similar to using surgery on some body organ, instead of finding the real reasons for a disease, more deep down. Like, the problem manifests itself in the heart malfunctions, but what it gets down to are the extras of the cortisol hormone, caused by stress. So, stress is the reason, not the heart.

Anyway, common sense and critical thinking are not the only universal best practices. Trial-and-error is a great best practice as well, but it does not apply to the heart surgeries (*black humor*).

Feedback Cycles

Retrospectives are one of the best practices for any agile software development methodology with a team-centric approach. You look back, evaluate what’s been done, see what could have been done better and make decisions for the future. Basically, a retrospective meeting can be visualized as a climax of a feedback cycle in a series of loops.

When there’s enough or more than enough feedback, then it’s high time for a retrospective. In Scrum, you can run an iteration-based or a release-based retrospective. If you do Kanban, a retrospective can be run, when a new build is released, or on a just needed basis. From what I’ve seen and read, quite often retrospectives fade out in Kanban, that’s also been the case with our team.

First, as we were doing XP, we used to run retrospectives by the book, for each iteration and for each release. Then we switched to Kanban and experimented with the retrospectives. Now, as we’re about to deliver the completely new TP3, the dynamics has shifted. We’ve seen that the things that used to work for smaller releases, don’t work now as we’re on our way to the new product. So we’ve called ourselves on a retrospective, although we haven’t done one in about 7 months. I’m using this as an example to make a point that there’s no boilerplate rule of thumb for retrospectives. No one, less likely an outsider, can sense the dynamics of your team as well as you do.

The following visual is an anti-pattern for agile retrospectives. If it happens this way in your team, it’s a sign of a serious disease. I’ll cover possible reasons and cures in the next part of the series.

Visualize Retrospectives

When at a retrospective, you need to create a context for discussion quickly. That’s where visuals come in handy. We  use screens, wall boards, colored stickers; certain colors may stand for critical-mild-urgent issues to address, etc.  But there’s no need to make  too big of a deal out of it. Obsessing over colors for stickers will not compensate the lack of team spirit, so first things first.

In fact, there can be a case when the context is already in place, e.g. a team comes to a retrospective already aware of the problems they should discuss. All the same, visuals will display the picture, and people’s brains will be busy making conclusions about the events, not keeping in memory all the events that are the basis for their decisions.

Visuals at a retrospective (or post-retrospective) support the following 3 activities:

1. Discover problems

Historical data needs to be reviewed at a retrospective. The data can tell that everything is going great, or that you’ve got some problems. The trick is to spend as little time as possible on retrieving the data,  and focus on the actual problem solving more fully.

Take a look at the cumulative flow chart below, I’ve pulled it from our previous history.  It shows that there was a bottleneck at the beginning of December.

As we tracked down the bottleneck, we were able to identify its reasons. The bottleneck was caused by a rather complex user story.  One developer worked one month to implement it.   During this month we did several releases, and everything went smooth. Then this user story was QAed, and all the acceptance tests were passed. So we decided to merge this story to the main code line.

Unfortunately, after the merge quite many bugs were found in the build. It took more than a week to fix those bugs, and during this time we were unable to release anything, since the merge was already done, and the rollback was quite hard as well.

The lesson learned is to put more effort into testing complex user stories. This particular story affected many places in the application and usual smoke testing was not enough. So we decided to introduce a new class of service (something like a  “technically complex story” ) which would require a more in-depth testing and verification before the merge.

The cumulative flow diagram works good to identify bottlenecks. We’ve got another chart, the timeline. It zooms in on the details of a user story life cycle.

This chart gives answers to a number of questions, such as:

• For how many days has this User Story been in this particular state?
• Were there any delays?
• Was there any re-work?
• Who was responsible for the User Story?
• When were Bugs and Tasks added and closed?
• How much time was spent each day?
• Were there any impediments?

So, this user story was in the Open state for 25 days (that is, in the Backlog). Then it jumped right into the 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 the 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, the tester found several bugs and they were fixed in 2-3 days. Finally, the user story was released to production with no more delays.

I’ve given 2 simple examples of how we use TargetProcess to support retrospectives. Another great visual we’re using is TargetProcess card rotter.

Historical data can be visualized in many-many ways ( check this article for some  inspiration).

You can also go from human moods and emotions to discover problems at a retrospective. Here’s a very simple diagnostics chart, the Happiness Radar (by Paulo Caroli):

People made some marks for the areas they’re happy, neutral or pessimistic about, and we can see that process and technology clearly lack happiness.

2. Solve Problems

As the problems are identified, you need to think about the solutions.  Mind maps work great to visualize problem solving. In fact, we do a mind map subconsciously whenever we discuss something and sketch the thoughts on a piece of paper. This simple yet powerful technique can be used at retrospectives as well, and that’s what we’ve been doing. Mind maps can be drawn on a board, or on a screen, or just on a piece of paper.

Check out this mind map. It has been used to think about the problems and activities that influence the speed of development.

Looking at this sketch, you can make a conclusion that only two things can improve the velocity directly: fast feedback and experienced developers (while there are many waste things, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt).

Visualization brings the issue of speed on a plate and breaks it down into smaller pieces:

• How to deal with customer requests and reduce unplanned work?
• What should we do with the urgent bugs?
• How can we do more training?
• How do we break work into smaller batches?
• What should we do about noise and interruptions?

If you ask questions like these at a retrospective meeting, you can expect  many good ideas. If you just ask:  “How can we work faster?”,  the answer might be silence and confusion.

In the previous example, the mind map is built as a network and inspires the goal-oriented questions. The 5-Whys root cause analysis  looks into the reasons, so the map would be sequential, going from one Why to another:

I picked up this image from Sandy Mamoli, as the problem they’ve been working on at their retrospective is quite common, and the answers to the 5 Whys are typical.

Now, in line with the Happiness Radar above,  that’s how they visualized possible solutions using  the “What will increase happiness?” chart with the “keep it”, “more of” and “less of” sections:

3. Follow Through on the Action Items

You’ve identified the problems, pondered over them and come up with some action items after a retrospective.  I’ve searched the web through and through, but to my surprise, it seems that very few teams are using kanban board as a visual tool to track their retrospective action items. It appears there’s a reason for that. With kanban, you need to have an opening state and a final state, it’s for straightforward one-time actions.  Contrariwise, retrospectives often reveal the need for recurring actions, of which not a single person is accountable, but the whole team. These are the collective ownership items.

For instance, you see that inconsistencies in user stories are discovered only at the final testing phase. You run this issue by a retrospective, and you decide that a user story launch meeting should be done before the start, and the inconsistencies should be taken care of at this very meeting (e.g. the specs should be discussed and approved). So, the action item here would be to include writing functional specs as a task for a user story AND check if all the stories that are currently in progress have the specs.

Back to the problem of over-promise and under-delivery featured above (a very common problem, by the way). Now, you decided to set limits to your work in progress. Someone needs to write mash-ups so the limits can be tracked easily on the kanban board. This is a one-time actionable item.

You also decided that urgent bugs deserve more attention. Someone should think over the process for such bugs.

Here’s a very basic kanban board with these tasks:

On the kanban board below, you clearly see the limits of your WIP, and the red light turns on any time when your WIP rules are violated. No need to keep the limits and the details in memory, the kanban board would send a visual signal about the problem  - a helpful follow-through for your retrospective.

Next, about the bugs. They are now tagged “urgent”  and “sup”, and they should be tracked closely+comfortably=visually. On the snapshot below,  the red cards stand for  the “urgent” bugs and the salmon cards for the “sup” bugs (“sup”  means “support”). This custom visualization has been done with one of our mash-ups.

There’s also the Team Load mash-up, that shows how much work, and which work, is in progress for every team member. Another good follow-through technique for  retrospective action items. Blue stands for user stories, red stands for bugs, team members are on the pics (including Voltaire :)

Continue to Retrospectives, Part 2: In a Sentimental Mood

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.

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.

Evolution toward Increased Ideality

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.

Technology Lifecycle

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.

Uneven Development of System Parts

“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.

Increased Complexity then Simplification (Reduction)

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.

Why do teams gel? Why some teams are trustful, enthusiastic and passionate; while other teams are apathetic and boring? There is no recipe to build a great team. You can’t add 5 grams of trust, 3 grams of fire, pour in some communication and boil till ready.

Why we need teams at all?

Working Alone

Team adds some new qualities in comparison with individual. When you program alone, you don’t need trust. Of course, you most likely trust yourself, otherwise you need  medical help. Besides you don’t need communication skills, if you speak to yourself very often you need medical help as well. All you need as a lonely programmer is problem solving, technical skills and passion to move forward. However, these are not enough to work effectively as a team.

If you work alone, you are free to make any decision fast. You have zero overhead: no meetings, no discussions, no phone calls, no questions.

If you work as a group of people (I mean, team), everything is not that shiny. Suddenly, you have to visit meetings. You have to participate in various discussions about technical issues and solutions. You have to answer questions and sometimes you have to do things you disagree with. Is that all so awful? Yes, it is.

So, why people do form teams? Simply, to solve problems that can’t be solved by a single person. Team is a necessity and it suddenly brings more formality to problem solving:

You have to communicate to have aligned vision. Otherwise you will solve two parts of the problem differently and solutions will not fit.
You have to coordinate work. Otherwise you will have huge delays and inefficient process.
You have to find common language to understand each other.

Team brings an additional overhead.

Working as a Team

In general, an effective team reduces overhead to minimum and lets people really solve problems and focus on main activities (I mean development). If we think about team from this interesting angle, we can easily find good practices to  improve team’s efficiency:

• Less people. Small team has less overhead.
• Common language. All should understand each other as quickly as possible. That is why offshore teams have huge problems.
• Less meetings. Ban all meetings and activities that don’t help to solve problems.
• Minimum people on meetings. Invite only those people who can really bring value to problem resolution
• Team isolation. It is generally a bad idea to have 2 teams working on different projects sit in one room.
• Fast communication channel. In general, the goal is to have less communication. Really. It is. It means if you have to discuss something, you should do that using the fastest available way, and it means in person talk most likely near a whiteboard.

But. Improving team’s efficiency, we can easily decrease team’s creativity. It may happen that team will solve problems quickly, but these solutions will not be the best. It may happen, that some unstructured chats about stupid things cause a genius idea. We can’t predict what will help us to find a really cool solution. Most likely we should not strive for complete rigid team that communicates only about problems and solutions. There should be a slack, and it is always there. People instinctively feel that unstructured chats are good and helpful sometimes.

Trust

You can’t have a good team without trust. Why? Simply because trust reduces communication time and helps to solve problems quickly. Imagine a team where people don’t trust each other. You immediately have political games, suspicious questions, indirect wording and rounded phrases. You have hidden conflicts, but polite discussions on a surface.

If you come and see this team in action, you will be astonished by stupid decisions and dumb solutions. Everybody’s goal is to cover his ass in such an environment.

Trustful team doesn’t spend time on all that shit. Discussions are hot and straight to the point. People can even scream on each other sometimes, but if they trust each other it does not really matter. They critique bad decisions fearlessly and don’t hesitate to provide fresh ideas.

Trust saves time on communications and leaves more time to do the real job.

Passion

We all saw people with extinct eyes. We all saw boring and semi-dead teams that work from 9 to 7 and can’t wait to leave the office. Nobody wants to work in this place. But still many do. I personally can’t understand why people do that. I don’t accept any usual arguments like stability, money, habit. I can’t work in a boring place on boring projects. It is not fun, it is not interesting, it is not valuable.

Passionate team is built from passionate people. That is it. They really care about what they do, they focus on real problems, they do everything to improve things. Passion is an ultimate team’s engine. No passion — no drive.

Wrap Up

Great software development team is built from passionate skilled professionals that trust each other. They collaborate effectively to solve problems and improve team work.

You are having your first project. In the beginning, you know almost nothing about programming languages, business domain, development process, efficient practices and other good things. In the beginning, you know almost nothing about political games, external factors, progress reporting, human stupidity, fear of mistake, boredom and other bad things. You can’t do your job effectively. Suddenly, in 10 years, you are becoming a great software developer. Or you are buried by mediocrity and never ride the wave. Why? What should you do to advance or just survive?

I think one of the most important factors is perpetual, passionate learning. Learning is the most important thing that drives software development forward. Learning is the most important thing that drives you, as an individual, forward. It drives your team, as a group of people, forward.

source: Ashiro’s LabZone

I believe, learning is a key attribute of a good software development process. Process that empowers learning will work, process that impedes learning will fail.

Basically there are three levels of learning. First, you learn as a person. Then you learn as a group of people. Finally, you learn as a whole organization. This post focuses on personal learning.

I have my own vision about software development. Most likely it comes from my personal background and products I’ve worked on (all of them web-based).

Software developers solve problems. To solve a problem in a cool way, you need to be a multi-skilled professional with quite solid knowledge from as many related disciplines as possible. Only this will give you a complete vision of the best possible solution.

Deep Specialization vs. Broad Knowledge

We are stepping on a slippery ground of deep specialization vs. broad knowledge. My belief is that at the current stage broad knowledge is better. Why? I can provide some analogies that prove nothing, but still are interesting.

Mass-production

Software development is a young discipline. It has its own properties that are not fully understood by most people. You can’t apply mass-production to software development so far, since you can’t formalize it enough. You can’t write a product specification, create design and generate complete application from UML diagrams (yes, I am aware about Model-Driven Development, but it is not even close to mass-production).

Look, there are so many related topics, from psychology to programming languages, from ToC to pair programming. There is no best way to write software so far. If you can’t apply mass-production to software development, you can’t do it efficiently with people who have a very narrow specialization. You can’t put it on a conveyer.

Science

Let’s take science and look back 300 years ago. We will see that many discoveries were made by generalists. Let’s check Wikipedia.

• Isaac Newton: physicist, mathematician, astronomer, natural philosopher, alchemist, and theologian.
• Galileo Galilei: physicist, mathematician, astronomer and philosopher
• Christiaan Huygens: mathematician, astronomer, physicist, horologist, and writer of early science fiction
• René Descartes: philosopher, mathematician, physicist, and writer

It was common 200-300 years ago. In modern science you can’t discover anything without deep specialization. There are people  with broad knowledge, but it is quite  rare these days. More often you will find people like:

• Barton Zwiebach: string theorist
• Max Tegmark: cosmologist.
• David Joseph Bohm: quantum physicist

There are rare exceptions for sure, like this one:

• Stephen Wolfram (born 1959): physicist, software developer, mathematician, author and businessman.

What is the point? Software development is obviously neither a science nor a  ‘tangible’ industry, so all such analogies don’t prove anything. But I think software development now is somewhere in 17th century compared to science and in 19th century  compared to usual industry.

With this in mind, a team of generalists with some specializations can create a better software than a team of highly specialized people. It is not obvious and we need to evaluate this assertion. I can throw some arguments:

1. Communication. Communication flows in a team of generalists. They understand each other easily and speak similar language. Communication in a highly specialized team is hard. If UI developer knows almost nothing about server side and server side developer doesn’t know Javascript, HTML and CSS at all, they will have hard time finding the best solution.
2. Architecture. Developer may know nothing about testability. As a result he creates a hard-to-test solution. High specialization can lead to local optimizations, but weak overall architecture. If no one understands how does it work as a whole — it’s a bad sign.
3. Fragility. A highly specialized team will hardly pass a “bus test”. If one of the key persons is hit by a bus, development will stop.

A Multi-skilled Software Developer

I believe in multi-skilled software developers. The right question to ask is “how much skills should I have and how deep?” It really depends, but here are the skills/domains/attributes every great web developer should have. The list is sorted by priority and I put hours that should be spent on formal education:

• Curiosity and passion
• Self-reflection / problem solving
• User Experience (1000 hrs)
• Programming (OOP/OOD, tools, practices, etc.) (8,000 hrs)
• Testing (200 hrs)
• “Sense of beauty” (Graphic design, visualization, etc.) (200 hrs)

I insist that these skills are very important for any really great web developer, but they may vary depending on software development type. I expect questions like “Why the hell you put User Experience before Programming?” The reason is that UX is an important part of problem solving. It is more important than implementation itself. UX gives developer the right perspective and makes a strong impact on software solutions. Without UX you can beautifully implement a crappy solution, and 90% of all existing software is exactly like that. IT’s crappy, unusable and bloated with unnecessary features.

Great developer should have a “sense of beauty”. It’s hard to formalize, but in general he should be able to say “this button is ugly” and “this menu is beautiful”. “Sense of beauty” is a very important property, it affects everything: visual design, documentation, architecture, source code. Everything. You can (and should) train it.

In the next post I will share my vision on Learning as a Team.

Today I’ve read two interesting posts: The Cost of Code by @unclebobmartin and Code as a Cause of Project Failure by @DocOnDev. They discuss various arguments to prove that all projects fail because of code. The main argument is that if code is free and light-fast to change, project can’t fail. OK. But this case is rather extreme and obviously impossible. We don’t live in a world with hyper-space jumps, teleportation and free medicine (unfortunately). In real life code costs a lot and it will be true in the next decades for sure, so this argumentation proves nothing. In ideal world there is no such thing as code. In ideal world you have a solution in seconds without computers, software and other complicated things. So I don’t buy this idea. Code is not the main reason for projects failure in reality.

Code is not free. Code is expensive. We do not sell source code though, we sell solutions. If it is possible to create a solution without source code, it would be fantastic. Let’s take an industry that handles tangible objects. Automobile industry does not sell carbon and metall — it sells cars. It sells a solution to transportation problem. Teleportation is an ideal solution, but we can’t teleport nothing but electrons, sadly. We buy cars to get from point A to point B. We buy a solution.

Code != Solution

I think the main problem with projects is that they provide either bad solution or no solution at all. Nobody buys stagecoaches these days, since there are more efficient solutions. If a project does not solve anything, it will fail. If a project solves something, but  in a nasty, unusable way, it will fail. You can create an absolutely beautiful architecture with the cleanest code in the world. You may have 100% test coverage, complete separation of concerns, flat hierarchies and methods without boolean arguments. You may have all that beauty, but still fail miserably if the program does not solve user’s problems efficiently.

You may argue that with clean code you can refactor it fast and change everything. C’mon, it will be a full re-write if it solves the wrong problem. Can you fix a stagecoach to make it a true competitor of a car?

On the other hand, if a projects solves a right problem, but with some issues, clean code is very important. You can’t adopt fast without it. You can’t change things and react to people demands.

Don’t get me wrong, I believe that clean code is an important thing, but it is not the most important asset in software development.

Since I started to work for TargetProcess and use the product for my daily working routine, I’ve experienced some problems. One of these problems was  navigation. All the links were grouped under sections in primary navigation level or administration level at the top. It took quite long to learn which group of links  should I select  to find some specific page.

The mind map of old navigation

Later I grew up to an experienced TargetProcess user as I’ve been testing new features or build every day but I still was mistaking the groups almost every time  (e.g. trying ‘Tracking’ instead of ‘Planning’ group when looking for Builds list).

Since navigation was the common pain we started to think how we can revamp its look and feel. We wanted it to be flat, customizable, easy to use and quick.

Wireframes

Complaints and requests from other TP users have been considered as we’ve been generating ideas for first wireframes:

We’ve been thinking if we should hide or show the whole group of links as on the screen below:

…and ended up with the concept of customization by links as we enabled users either to pin each single link to primary nav tab or to keep the link in ‘More’ group, create their own groups and rename the links:

All these wireframes emerged after long meetings, hot debates and multiple changes.

Concepts

As a result, by mid-January ’10 we’ve had two different navigation concepts ready to be shown to some customers, members of TargetProcess UX group. We asked the customers to review two navigation concepts implemented as dynamic and static PDF and give us their feedback on both.

Here’s the first navigation concept:

1. One-level menu for quick system navigation.
2. Configurable tabs order.
3. Quick access to all pages grouped logically in “More” pull-down menu.
4. Easy-to-use advanced tuning mode.

The second navigation concept:

1. Two-level menu.
2. Configurable tabs with the possibility to re-group links.
3. Easy-to-use advanced tuning mode.

Most of our customers-UXers voted for the first concept and we went along with this design. Development of dynamic prototype was started simultaneously with the nav coding so we had usability test results available by the end of implementation.

Dynamic Prototype and Usability Tests

We wanted to run a usability test with our customers as early as we could and the interactive dynamic prototype for navigation was ready in a week (with IxEdit). The prototype replicated TargetProcess tool and was available on the web. Not like in the real web app, there were just screenshots with static pages:

In this proto users were able to navigate from page to page and to customize links selection for their primary nav menu. The only major thing at that time was re-ordering of pinned tabs which didn’t work in the proto.

Test scenarios were rather simple:

1. As we drastically changed the layout and re-grouped some links, we wanted to check if users will find particular pages easily with new navigation . So the first scenario was about simple pages browsing.
2. The second scenario was related to the customization of primary navigation level.

We asked our customers from the UX community to take part in the usability testing of new navigation, and four of them agreed. The testing was done via GoTo meeting.

Usability Tests Results

Based on the results of this testing, we’ve become aware of some areas in the navigation where users slowed down.

Most of the users who saw the nav for the first time tried to drag and drop links right away and guessed slowly that tuning and re-ordering tabs works in customization mode only. After customization was done, they forgot to switch customization mode off. Also we noticed that [Reset to default] button appeared uncalled, so it was removed in the final version.

That’s why we went on and tried to emphasize with different styles when navigation is in customization mode and when not.

Now the highlighted menu background under the button [Customize] shows that the button should be pressed to start tuning (customization).

That’s what one can see in the tuning mode (check the screen below):

• [Customize] button disappears; yellow background rolls up to the primary nav level where [Done] button appears.
• Only the primary nav level and  ‘More’ menu are active, content of the page is grayed out and disabled.
• Links selected for relocation in ‘More’ change their background from white to solid blue; mouse cursor changes shape to cross.

We believe that it’s hardly possible to mess up with the navigation modes now. The navigation is quick, one-level and simple for personal customization.

And – what’s most important – people like it as well. Out of many feedbacks, here’s just one from Igor France:

I have just installed the latest version of Target Process with the intention to start using it on my own projects (the company I worked for at the time didn’t adopt it) and I am again really enjoying using it! Apart from the positive things already mentioned, the main navigation itself in the meantime not only stopped being confusing but is now fully customizable as well!

“You can’t apply Scrum without an external expert”
“You can’t apply Scrum without a Certified Scrum Master”
“You can’t apply Scrum without XYZ”

You can replace Scrum with any other buzzword. Is it really necessary to have an agile coach on board to join agile camp? Is it really required to send someone to CSM courses and delegate Scrum adoption to this brave knight in a shiny armor? I believe it is not the only way to go, and there are 2 reasons that support my vision:

1. I did not attend any courses, conferences and other events, but I did learn agile and became an agile expert.
2. We implemented agile process in our company without any external help.

To me it looked (and still looks) natural to improve development process internally. It was an ad-hoc agile adoption  in our company. There was no defined structure, but on-going learning. People have been reading books about agile development which I recommended. I’ve been making some presentations about agile history, main processes and so on. People have been reading articles and discussing new ideas. It worked out, finally. Even with such an unstructured approach you are able to set up an agile company. But are there better ways?

Agile Coaches

What’s wrong with external coach/trainer/consultant? Nothing, actually. You pay someone to teach you. You pay someone to inject agile culture into your company. You pay someone to get it faster.

The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can’t speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can’t absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don’t need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.

OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can’t setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

1. If you hire agile coach, it is better to have about 1 year contract.
2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can’t accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.

So why I personally don’t like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can’t we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we’ve already given up and can’t do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.

Don’t get me wrong. Agile coach can help greatly. But I don’t buy the paramount idea that development team can’t go agile without external help.

Problems and Solutions

I like challenges and like to solve problems without external help. What I like is a full team involvement and participation. It is so cool when people discuss problems and generate solutions. If I ever hire an external consultant, it will be a person who will teach how to solve problems. Problem solving is the MOST IMPORTANT skill (can I stress it more?) for any good developer/tester/designer/you-name-it.

Here I see a major flaw of Scrum as a methodology (so far?). It does provide a framework, but it says nothing about problem solving. OK, you should have a retrospective meeting every other week. You should identify problems, generate ideas and write action items. You should execute action items and retrospect in 2 weeks. Sounds good. But HOW to identify problems? HOW to generate ideas? Scrum says nothing about that, but I believe this should be the core of any agile process.

That is why I pay more and more attention to lean and other problem solving techniques like 5 Whys, TRIZ, etc.

Knowledge From Within

There are various ways to ignite the team and solve problems internally, but you can’t solve problems effectively without knowledge. Study Groups could be the most promising way to educate people. To be honest, we did not try it. As I mentioned, we did not have any structural approach so far, but intuitively came to something similar to Study Groups.

Study Group is a small group of people (4-6) that have cadence sessions e.g. weekly. There’s no distinct leader, they rotate with every session. People should be really interested in the domain. For example, if you have Study Group to learn TDD, all the members of the group should be passionate about TDD learning and actively participate in discussions.

Why I think Study Group should work? First, there’s no Boss inside. People can freely discuss various problems without pretending that they know everything. Second, there is a clear focus. You should not form a group with a goal to solve all the development problems, instead it is better to form groups to study UX, study TDD, study Scrum, study Lean. Once again, Study Group is not a problem solving technique, but it helps to educate people. And it is absolutely clear that educated people will generate better solutions faster.

Here is the nice summary about Study Group. And here is the list of other learning methods that every agile team should pay attention to.