dzone_url = "http://www.targetprocess.com/blog/2010/07/using-paper-to-sketch-ipad-app.html";

Sketching is not so hard. It is really interesting to sketch something with basic tools. Here is an attempt to sketch a Mind Mapping tool for iPad. It is real fun to sketch for a touch device. In fact, that was our first experience with paper animation and video techniques, but I think the end result is good enough for 6 hours of work (taking into consideration that we’ve learned iMovie on the go).

The application is pretty simple. You can create nodes and connect them, delete and move nodes — all with simple gestures.

The video goes at 2x speed. It is more dynamic this way, but maybe  some details are lost…?

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/07/book-review-1-sketching-user-experience-by-bill-buxton-part-ii.html";

Read first part of the review.

Evaluating Design

There are two important aspects of design process: generative and reductive. We generate a set of alternatives, then we restrict this set based on various criteria. It is impossible to evaluate a solution without its alternatives.

The best way to a good idea is to have lots of ideas — Linus Pauling

I can’t critique just one thing — Richard Sewell

That is one more reason why sketching is so powerful. It helps to generate and evaluate various alternatives. I’ve read in one article that Apple creates a dozen alternative designs for any product. Good enough…

One of the most positive form of criticism is a better idea

Acquiring positive attitude to criticism is a hard change. People don’t like to be criticized in general. You can’t get the correct reaction to criticism out of the box, but should apply every possible effort to make it a part of team’s culture.

People on a design team must be as happy to be wrong as right. If their ideas hold up under strong (but fair) criticism, then great, they can proceed with confidence. If their ideas are rejected with good rationale, then they have learned something. A healthy team is made up of people who have the attitude that it is better to learn something new than to be right

Built to Last

Without appropriate design, yesterday’s success is tomorrow’s failure, since today’s great applications are tomorrow’s legacy systems

Some design decisions live for about 20 years if product is successful. For example, Photoshop has been on the market for 20 years, and some parts of its initial architecture still exist. Can you now imagine how important architectural decisions are? On to entities framework in TargetProcess that was designed 4 years ago. How long will it live? Definitely we did not consider a 20 year time frame back then…

We should assume that technology that is going to have a significant impact over the next 10 years is already 10 years old!

My takeaway lesson is that we should pay more attention to new technologies and think ahead at the same time. This may sound impossible, but it is worth trying.

Learning

Learning is a very important thing. No, I will re-phrase it. Learning is the most important thing in your company. Surprisingly, Bill has given an interesting perspective on learner’s experience levels:

I haven’t seen this concept of levels before, and I like it very much. If we take agile, I am in transition between levels 9 and 10 (I think). In UX, I am between levels 5 and 6. This model is a good guide and may help understand and plan personal or even corporate learning process. Is it possible to apply it to the whole company? Maybe.

Story-telling and Play

A good story is worth thousands of pictures

That one is true. For example, Steve Jobs told 3 stories from his life at Stanford Commencement Speech in 2005. And this speech was remarkable indeed. I remember all the 3 stories, despite the fact that I heard them only once.

Without play imagination dies

and one more:

Stories, and more importantly, story-telling and play, are critical part of design

Ever been on a boring brainstorming session? Fun is an essential part of any creative activity. It should be encouraged, not suppressed.

Design

Finally, some outstanding quotes on design:

Design is a funny word. Some people think design means how it looks. But, of course, if you dig deeper, it’s really how it works. To design something really well, you have to ‘get it.’ You have to really grok [understand] what it’s all about — Steve Jobs

The last thing that you should do when beginning to design an interactive system is write code

The role of design is to find the best design. The role of usability engineering is to help make that design the best.

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/07/book-review-1-sketching-user-experience-by-bill-buxton-part-i.html";

I purchased this book at UXLX conference in Lisbon. I did not expect too much of it initially. But after several dozen pages it paid off every cent I’d spent and exceeded my expectations in every possible way. This book is for UX designers, yes, but I’d say every executive should read it. There’re so many gems inside.

I can’t resist sharing my takeaway lessons. The ones that impressed me most.

Executive Vision

Everyone knows that Steve Jobs saved Apple after his comeback. But Bill provides a nice and somewhat unexpected perspective on iMac release lessons learned. I highlighted the points that seemed most important to me:

1. Design saved Apple
2. The design innovation was done with the existing team
3. Executive vision was critical to success
4. Momentum was sustained and rapid (the iMac alone did not save the company, repeated improvements did)
5. There were failures (hockey-puck shaped mouse [see image], Power Mac G4 Cube [see image])
6. The failures were key to success (in the long term, safe is far more dangerous than risk)
7. The design that led to success was largely in the realm of styling, bordering on the superficial
8. There was almost no interaction between industrial design and user interface design.

This story re-emphasizes the importance of leadership. People haven’t changed, it was the same team, but with the great leader they managed to create a brilliant product. Which impediment have they had until Steve came into the spotlight? Lack of executive vision. If there’s no vision and you don’t care too much about design, failure is the most expected result of a new product release.

Actually, I felt the same about a year ago. That’s why I am paying so much attention to UX: reading books, blogs and articles, visiting conference and, of course, championing UX changes in our company. Bill’s book once again instilled me with passion and with confidence that we are going in the right direction.

“It is important to establish a corporate culture that understands and respects the design plan and objectives…”

New Products

“You can’t milk that cow forever” — this quote relates to old products. Company can’t survive without new products, and here is why.

“As product reaches late maturity, development cost for the next release increases at precisely the same time that the size of the addressable market diminishes.”

This is not the case with TargetProcess so far. Our market is still growing, but development cost indeed gets higher. That is something I don’t like and want to change. There are plenty of technical debts we should pay and features we should remove or re-work to be more simple and consistent. We are already doing that. In several years we should release something new, something different than TargetProcess (frankly, we already have plans for some new products).

Sketches

Sketches are very important for design process. They help to explore alternatives and quickly try them. Without sketches it is really hard to find the best solution. I like sketching and do it often, but Bill provides very good reasons and explanations why and how sketches work.

First, it is interesting to define properties of a sketch:

“Sketches are:

• Quick
• Timely
• Inexpensive
• Disposable
• Clear vocabulary (style signals that it is a sketch)
• Distinct gesture (fluidity that gives sketches openness and freedom)
• Minimal detail (“it is usually helpful if the drawing does not show or suggest answers to questions which are not being asked at the time”)
• Suggest and explore rather than confirm
• Ambiguity (much of their value derives from their being able to be interpreted in different ways, if you need to get the most out of sketch, you need to leave big enough holes)”

Here are the main conclusions I’ve made about sketches:

• Ability to quickly generate many ideas. Sketches stimulate imagination and you may invent something initially unexpected. That’s what’s important. I’ve never thought about sketches this way, I always use them as an ideas evaluation technique, but this side effect is brilliant.
• Sketches are useful to express ideas. They do not interfere with changing and improving the ideas, since they are not “final”.

Another important thing is that “Sketches are not prototypes”.

Read second part of the review

Related Links

Sketching User Experience Book at Amazon

Bill Buxton’s web site

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/06/fridays-digest-18-scrum-vs-kanban.html";

Many interesting posts and discussions about Scrum and Kanban published last weeks. Someone even called this a war I don’t think it is a war, but some posts indeed may drive such feeling.

• Ken Schwaber bashed Kanban. “I was told that Kanban is frequently used when an organization cannot readily adopt Scrum. Many of Scrum most difficult aspects are then sidestepped. Managers are still in charge of telling people what to do. People can be interrupted at any time. People are still work in functional silos, preserving the jobs of functional managers. People are not allowed to work in containers, sharing skills and knowledge to bring complexity into solutions – instead they are worked on a pull (more sophisticated than push) production line.”
• Karl Scotland discusses Scrum and Kanban difference as Intentional vs. Implementational approaches. Interesting perspective in fact. Karl thinks that Kanban can be used with Scrum to reveal even more problems in development process.
• David J. Anderson posted the most rational article about Scrum and Kanban difference. I like it a lot. Some phrases are true gems: “Kanban is not a project management or software development lifecycle method. It is an approach to change management - a framework for catalyzing change in an organization.” and “Kanban uses a WIP limit as a change agent and Scrum uses commitments. This is a fundamental difference in approach.” David also posted some reflections later with interesting thoughts about anarchy and science.
• A year ago Tobias Mayer didn’t believe that it is possible to use Kanban at all. “I fundamentally disbelieve that there is any such thing as a “value stream” when you are working in a complex environment, in a creative process, building new products or generating new ideas.”

I think Ken is wrong. His arguments against Lean and Kanban quite ridiculous. Sure there is no intention to treat software development as a factory and apply lean manufacturing principles blindly. Of course there are people who will try (or already tried) that and fail. But vast majority of lean community in software development do understand the difference and working on concrete practices. Lean philosophy is great, but tools and practices can’t be taken from manufacturing directly.

Pull system is more complex than Push? C’mon!

David has wise arguments and perfect position. I think Kanban will be more popular than Scrum in long-term perspective, but it will take time. Visualization is a key thing to manage complexity, and software development is a complex system.

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/05/ux-lx-takeaway-lessons.html";

I haven’t attended many conferences in my life. To be honest, agile conferences disappointed me. Agile 2009 was half boring, half OK with just one mind-blowing keynote by Jared Spool. As you probably assume, he talked about UX. In fact, this talk has changed many things in TargetProcess, as we started incorporating UX into the company culture. And this is the only reason why I can give Agile 2009 a “good conference” label.

We decided to visit UX LX in Lisbon to check whether there’s any difference. I am an expert in agile, but novice in UX. Conferences are good places to re-charge batteries and to fuel vision. UX LX fully met my expectations. It. Was. Cool.

So what I’ve learned? What we’ll try to apply at TargetProcess soon?

Brainstorming

Maybe this is a number one and Dan Saffer did a really great job at the workshop. To be honest, brainstorming sessions sometimes were boring at TargetProcess. We used several whiteboards and markers. The process was synchronous. It means one person grabs the marker and writes something on the board. Other people throw out ideas and suggestions. Sometimes it works, but there is a much better way.

It is a very good idea to separate two activities. Brainstorming phase may be asynchronous. It means all people can brainstorm the problem and sketch/write results/ideas. There are several techniques that help. One of my favorite is brainwriting. You have a problem and everyone has a sheet of paper. You have 1 minute to write or sketch anything related to the problem. It may be just few words or a very brief sketch. Then you pass the sheet to the next person and receive a similar sheet from the person at the left hand. You see absolutely new content and have 1 minute to understand it and expand it. Very clever and fun.

Photo by Adaptivepath

Also it is very important to engage everyone. Use wall, sticky notes and paper to break down ideas into groups. Then you may review every idea and decide what to do with it. Group interacts with physical objects and these simple activities boost engagement. Also you may give some simple gifts for really cool ideas. It sounds silly, as Dan said, but this works!

Emotions

During one session I understood that TargetProcess is  (quite) a boring product. It has almost no emotions inside. It should be more emotional and humanish. Out of the box ideas are:

• Use avatars and real people faces
• Use better wording in dialogs, navigation, etc.
• Make it more personalized

Copywriting

Text is important. It is really, really important. If someone looks for information, finds the page, reads the text and has no clue what that mess of words is all about — that’s really bad. You might have a beautifully designed web site, but if the copy was written by a marketer or developer with poor writing skills — it will not be effective.

Eric Reiss ran fantastic workshop on copywriting and showed how poor wording can literarily kill a product.

Visualization

The truth is that visualization is hard, but if applied well may lead to unexpected boost of satisfaction. There is a lot of data in TargetProcess, but visualization is not so good. Many areas can be improved. We should pay attention to data visualization all the time.

Source: Swarm

Async Usability Testing

We tried synchronous usability testing on new navigation. It works perfect, but there are less intrusive methods to gather interesting statistic via async usability testing. For example, we can try daily notes or true intent studies. I clearly see how daily notes can be used for installation experience. We just ask a person to install TargetProcess and write everything during this activity (emotions, thoughts, problems). True intent studies may be context-dependent and it is a quick way to gather some interesting data in just a few minutes.

The conference was very good. I feel refreshed and full of new ideas. Also, I feel that in general we are on the right track about User Experience at TargetProcess, but some tactics should be changed.

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/05/how-less-value-turns-into-added-value.html";

We live in the age of added value. It’s everywhere. Value-added services, value-added products, value-added goods etc. etc. etc.  Actually, so much value has been pumped up in our life, that it’s even strange that this value is not protruding from us like clothes from an overly packed vacation suitcase.

If we take a closer look at the back side of added value, a huge surprise is waiting there. The example I find most notorious is cell phones. What if I want a simplistic cell phone with NO Internet, no camera, even no voice mail, just live calls and SMS?  You’ll never ever find such a phone.

I bet that a phone manufacturer who stops the rush for more new features, would make a fortune in an instant selling the “new frugal” cell phones. In this case, the added value is content which comes from Internet, capabilities to exchange content. Why should someone want a phone with Internet?  My word, very soon we will see such phones on the market. The niche for them is already there. Here’s why:

More content and more various channels to produce and exchange content is now commonly presented as added-value. Hence, a communication device which happens to be a humble phone is supposed to deliver this value. But as we’re oversaturated with content, no buzz is a huge deal. The luxury of focusing on one thing at a time is something that only a few can afford. Besides, it’d be very frugal (frugal is actually the new buzzword to buy a phone for a reasonable price, and sell used iPhone to some geek. Oh, pardon me. It’s all about iPads now

There’re plenty of such examples. Another one: the added value of having a car means lack of natural movement, the necessity to pay for gym etc. It actually brings along the whole array of more added value  goods and services that turn out to be not of added value but of less value, since you pay for what you could do naturally.

Take organic products. Now they’re added value. 100 years ago who could have thought that something natural adds value? Now it’s a rollback. What is simple and natural costs more, but has less value compared to the original added- value concept for the matter, and the cycle goes on and on.

And we’re nailing it down to our favorite: project management tools. Versatility and too many features now have bounced back to the simplistic Kanban board.

It looks like it’s time to not only practice lean production, but to produce lean products. Gaining focus requires focused tools, one way or another.

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/05/uncensored-report-how-we-created-the-new-navigation.html";

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!

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/04/product-backlog-small-steps-vs-giant-leaps.html";

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:

That’s how User Stories lifecycle looks on  Kanban board, from Planned state 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.

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/04/agile-conferences-look-to-no-epiphany.html";

If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc.  Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives.  Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences

I tend to think that with all the  information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile  - it’s hardly that something will be totally new to you (”totally” is the keyword).

Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) .  As opposed to most attendees,  I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team I’ve seen a bit of those “paper sword fights”

After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way  (including live jazz night in Krakow).

This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration.  In a sense,  that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire  even if this is your first experience as a speaker.

And.. it’s great that there’re many more agile conferences to come

var dzone_style="2";

dzone_url = "http://www.targetprocess.com/blog/2010/04/going-agile-from-within.html";

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

var dzone_style="2";