Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

• Mary POPPENDIECK (USA)
• Henrik KNIBERG (Sweden)
• Danko KOVATCH (Israel)
• Marc LOFFLER (Germany)
• Paul KLIPP (Poland)
• Anda ABRAMOVICI & Sudhindra RAO (USA)
• Robert DEMPSEY (USA)
• Vasco DUARTE (Finland)
• J.B. (Joe) RAINSBERGER (Canada)
• Mack ADAMS (Canada/France)
• Robin DYMOND (Canada/USA)
• Yves HANOULLE (Belgium/France)
• Monika KONIECZNY (Poland)
• Andrea HECK & Tibor VIDA (Germany & Hungary)
• Allan KELLY (UK)
• Dr. Johannes MAINUSCH (Germany)
• Sergey DMITRIEV (Norway)
• Piotr ZOLNIEREK (Poland)
• Sergei ANDRZEEVSKI (Russian Federation)
• Andrea PROVAGLIO (Italy)
• Pawel LIPINSKI (Poland)
• Nikita FILLIPOV (Russian Federation)
• Pavel GABRIEL (Belarus)
• Artem SERDYUK (Ukraine)
• Mikalai ALIMENKAU (Ukraine)
• Timofey YEVGRASHYN (Ukraine)
• Michael NORTON (USA)
• Pawel BRODZINSKI (Poland)
• Francois BACHMANN (Switzerland)
• Jurgen APPELO (Netherlands)
• Zsolt ZSUFFA (Hungary)
• Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!

• Tweet This!
• Post on Google Buzz
• Add this to DZone
• Share this on Facebook
• Share this on Reddit
• Digg this!
• Share this on LinkedIn
• Share this on Technorati
• Share this on del.icio.us
• Share this on FriendFeed
• Add this to Mister Wong
• Submit this to Netvibes
• Add this to Ning
• Stumble upon something good? Share it on StumbleUpon
• Add this to Wykop!

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.

 

Here's a quick video of the Agile Planner, so you can see it in action.

There appears to have been a data center outage early morning, affecting a number of applications including Pivotal Tracker. This has caused connectivity problems for users in some locations, and it appears to still be persisting for some.

We're working with our hosting provider to get this resolved as soon as possible, this is our top priority.

This is the second data center outage this week. At the moment, we do not have enough information to know whether the outages are related.

Also, we have received reports that Tracker has been unreachable from certain parts of the world (including China) since the migration to a new data center last week. We've filed a request with Engine Yard to investigate, and hope to have this resolved soon.

Our apologies for the inconvenience these outages have caused. We'll post more information here as we receive it. You can also follow @pivotaltracker on Twitter for updates.

By Steve Miller

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

Team Composition

Managing Scrum development requires a major change in how teams work together. In traditional Waterfall development, teams normally have a project sponsor, a project manager, analysts, designers, programmers, testers, and documentation specialists. Each team member has specific duties which normally do not normally overlap and they have a specific reporting structure (most team members report to the project manager).

With Scrum, you have just 3 team roles and is normally limited to 7 or less individuals (however, you can have multiple Scrum teams in sets of 7 or less):

• Product Owner - This is the person that identifies and prioritizes the features that will appear in a 30 day sprint. This is normally the Product Manager, CTO, in some cases the CEO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product. Before a sprint begins, the Product Owner communicates the goal of the sprint to the team and what features should be analyzed for the release. This does not mean that all the desired features will make it into the sprint, the team estimates and prioritizes items for the sprint (during the Sprint Planning sessions), and only the items that can fit in the sprint are done.
• ScrumMaster - The ScrumMaster is akin to the Project Manager in Waterfall environments, but does not manage the team deliverables at a micro level. Instead, this person is responsible for ensuring that the 30 day sprint stays on course, no new features are added to the sprint, code inspections happen, and ensuring everyone plays by the rules. The ScrumMaster coordinates and runs the daily sprint meetings. The ScrumMaster is not a task master, they are a leader that empowers the team members to deliver the assigned tasks and to help eliminate roadblocks that slow them down.
• The Team - With Waterfall, a team consists of analysts, designers, testers and documentation specialists. With Scrum, each team member is empowered and expected to self-manage themselves and to participate in all duties needed to deliver a feature. This includes analysis, design, coding, testing and documentation. The Team is responsible for staying focused on assigned tasks, soliciting help as they encounter road blocks, fully testing their code, refactoring code, logging their time daily (including estimated time remaining on each task), and for checking their code daily or more often if possible.

Our Experiences with Team Composition

In our experience, it is unrealistic to assume that The Team can handle quality assurance and documentation well. We have improved the team composition to include 2 additional roles:

• Software Quality Engineer - This individual is responsible for the quality of the sprint. In our experience, programmers do not test code with the same mentality as a Software Quality Engineer (SQE). Once specific requirements are defined, the SQE develops a set of test cases (manual or automated) to test each requirement fully. Before coding begins, the test cases are made available to the programmers on the team. The programmers are expected to run each test case before marking coding as being complete. Once a requirement is marked as being complete, the SQE is responsible for running the test cases again to ensure they all pass. The SQE also runs a weekly regression to ensure that legacy features are not compromised by the release. If the SQE has developed automated test cases for regression, those are run daily or more frequently, if needed. The SQE does not wait until the end of the sprint to begin testing, they test once a requirement is completed. By the end of the sprint, all testing has been done and regression has been run frequently.
• Documentation Specialist - The Documentation Specialist (DS) is responsible for creating User Guides, Administrator Guides and other training materials. In our experience, programmers do not always have the written communication skills to write documentation in a way that a laymen can interpret it, that is why it is important to have a separate resource for this function. Once a requirement has been fully tested by the SQE, the DS begins the documentation of that requirement. The DS does not wait until the end of the sprint to begin this, the end of the sprint includes all completed documentation.

The folks at AlertGrid posted an article with instructions for configuring Assembla to send SMS messages to your phone whenver something important happens. They asked "Can Assembla send me SMS message when new milestone is created?" Yes, it can.

The key ingredients are

• the Assembla Webhooks tool, which will send events from the activity stream to other applications.  You select the type of events that you want to send (for example, code commits, ticket comments, or new/edited milestones).  Then, you configure the URL to get or post the information.
• The AlertGrid service.  AlertGrid will not only send you an SMS, but it will compare the incoming messages to workflow rules, and send the correct message to the correct people.  So, this adds an extra layer of intelligence to the notification process that you can use to filter out noise and find the most important events.

Ah, Marketing.  Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.

Sound familiar?  In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.

In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning.  In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.

10 Steps to Successful Marketing using Agile and Lean Practices

1. We recognize that Marketing has challenges that are different from Development.

• There is no unique product owner.  For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
• We face hard event deadlines set far into the future.  Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
• Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth.  So one shared backlog is inefficient.

Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.

2. Conduct an ORID to learn from the past

Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs.  We gather as a team to share:

• Observations (O) – What do we know?
• Reflections (R) – How do we feel about this?
• Interpretations (I) – What does it mean for the organization?
• Decisions (D) – What are we going to do?

This strategic overview helps set context for us to prioritize our focus for next quarter.

3. Align ORID decisions with company strategy

At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done.   As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level.   Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.

4. Poll our stakeholders

As part of determining quarterly commitments, we poll our major stakeholders for their top requests.  We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.

5. Conduct Release Planning to prioritize and agree on quarterly commitments

Now that we have all of our inputs, we hold our quarterly Release Planning session.  We write each epic on a sticky note and look at all of the possible work we could do this quarter.  Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team.  We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.

Part 2 – Meet our Marketing Commitments

6. Create a task board

Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board.  This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.

As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one.  We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.

Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit.  As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.

7. Hold iteration planning every 2 weeks

Every 2 weeks, we hold an Iteration Planning meeting.  Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story.  In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance.  Then we hold a brief retrospective on what worked and what should change for the next iteration.  Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog.  This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.

8. Conduct a daily stand-up

At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long.  We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control.   As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on.  When the story is complete, then we move it to a place on the task board labeled “Done”.  Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.

9. Be patient as things change

It would be lovely if nothing changed during the iteration, but that just doesn’t happen.  The goal is ultimately to respond to change rather than cling to an outdated plan.  As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok.  We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.

10. Retrospect, inspect and adapt

As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them.   Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

by Martin Harris

I went along to the London Scrum User Group yesterday evening.  For a change it was a quiet night.  Christmas is around the corner so we had less attendees.  Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum.  After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack.  So we stopped there and got on with eating the snacks and drinking the beer.  So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment? The London Scrum Groups 6 Good Scrum Tips

• Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
• Run Retrospectives. Its very important to take actions away from a retrospective.  Be realistic though, your never going to solve them all, so ask the team to priorities them.  If your doing the retrospective right your product owner will be there to help with prioritization.  If you find something very big lands at the top, split it down into stories.  Otherwise pick one or two that the team feel strongly about and turn them into stories.  Make sure these stories are included in the next game planning sessions and make it into the iterations.  If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time.  Commit to doing them and then deliver.
• Ask your team to Pair Code. The XP technique of two programmers working on the same task.  It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput.  Don’t be dogmatic, let the team decide how much work should be pair coded.
• Setup Self Directed teams. Self directed teams have been proven to be more efficient.  We discussed the role of a scrum master in a self directed team.  Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks.  The scrum master does not plan or allocate tasks.  The empowered team needs to work out what the tasks are and find out how to finish the stories.  The scrum master should spend his efforts removing blocks for the team, checking quality.  Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed.  We also decided that to be empowered you need to make the team multi discipline.  Include testers, user interface designers etc to remove hand off waste and increase team knowledge.  With role diversity comes better decision making.
• Deliver what you commit to. Another gem, it sounds obvious but is so often ignored.  Delivering builds trust in the team and the process.  Classic ways to miss delivery include: Failing to produce a strong definition of done.  The definition should include the programming, integration, testing and setup tasks.  In fact everything required to get that task ready for delivery.  Another way to miss delivers is to fail to demonstrate at the end of the iteration.  You may think your done, but when the product owner sees the work for the first time they may request refinement.  If you have kept your product owner close then the demo is likely to be painless.  No power-point slides please, only real working software in the demo!  So commit and then deliver what you commit to.
• Co-locate your team. The group defined co-location quite tightly.  Co-location is not putting everyone in the same office.  Its putting the team members next to each other in the same space.  Intra team communication does not happen with the team scattered around an office.  You should be able to turn around and join the stand up meeting.  This closeness, speeds up the myriad of tiny important messages that pass around the team.  Some of which is non verbal.

After this rich discussion we gave up on the 15 tips idea.  If your doing these, then your doing very well indeed, and are likely to get better over time.

So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry.  Why not come along to the next one, we could use your input.

Below is an excerpt from an email response I sent someone asking me about Kanban and Scrum and what they should do to determine which is more appropriate for their teams. This is just my personal opinion on this subject and I’m sure our trainers have MUCH better perspective to add! Kanban for software is an [...]

by Artem Marchenko

Daily Scrum also known as daily standup meeting is an important element of the Scrum process. The structure of the meeting is quite rigid and fixed. Everybody has to stand up, meeting should take no longer, than 15 minutes and everybody should answer three questions: "What did you do since the last meeting?", "What are you going to do until the next meeting?", "What impedes you from being more productive?". The purpose of this rigidness is for making sure that daily Scrum is to help team members synchronize between themselves, not to solve problems.

Things to watch during the daily standups are:

1. Standup means stand up, no sitting, really.
Standing up on the daily Scrum draws attention to the brevity of the meeting. The purpose of the meeting is synchronization and no lengthy problem solving. Standing helps to remember that problem solving except the smallest one has to be taken offline - nobody likes to stand for an hour while two guys are arguing about the protocol implementation details.

2. Keep it short. 15 minutes max.
Everybody can spend 15 minutes a day on synchronizing with the others. Especially if it happens to be immediately before or right after the lunch time. Spending half an hour is a very different story. In my experience most of the time the 5-6 person teams are usually done in just 7-10 minutes.

3. Stand in front of the visual progress artifact.
Ideally in front of the task board together with the product and sprint backlog. Visuality and tangibility help discussing things. If task board is used, developers often like waving hands towards the card being currently discussed or even move the cards during this meeting.

4. Everybody should be present.
One of the main reasons for meeting live is to utilize as wide communication bandwidth as possible - people are known to communicate more effectively, when meeting live. If particular team member is unable to participate, another person should report on behalf of his/her. If it is impossible for some reason, catch up later.

5. No typing.
Holding a laptop and making notes is power. The one who types immediately starts looking as a manager and often subconsciously starts writing what he thinks was meant, not what team members actually said. If you need notes, take micro-notes by hand.

6. Concentrate on the second and third question, not on the first one.
What's done is more of a context for the second and third questions. The real point is to figure out what's blocking the efficient work and who could help it.

7. If team talks too much to ScM, tell him not too look at the team.
Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master.

Daily Scrum is a powerful tool, but as any other tool it is good, when you know what it's useful for and have some experience in using it. The above seven simple tips can be good starting points or reminders. However, every team knows best how to adjust its standups to serve them better. The important part is the goal, not the method.

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";

I am passionate about design; if it were not for the boom-bust cycles in architecture, I would have followed that education/career path.  As a result of that passion, I got really excited when I saw HiveLive four years ago.  So excited in fact, that Rally jumped in as key first customer and based Agile Commons on HiveLive’s platform.  I even personally invested in the effort led by three Kembel brothers: John, Jeremy and Geoff.  Last year, HiveLive’s  journey took another turn as they sold to RightNow. After meeting RightNow’s David Vap and speaking with a good part of their technical team,  I would say John, the VP of Social Solutions, is right that they made a great move.

John’s design-thinking approach was front and center to HiveLive.  It came from his background at Standford’s design school and a stint at IDEO.  As I got to know John, he mentioned all the great things going on with his other brother and twin George.  George was busy creating a new version of the design school, called the Stanford d.school.   The new d.school has broadened beyond just a partnership of art and mechanical engineering to become a interdisciplinary school that brings design thinking to all majors.   As I learned more about this, I started pulling on John’s shirt to get me out there so I could go see the place and meet George.  Well last week, I participated in the first ever d.social summit for two days with 15 folks focused on the intersection of design thinking and social thinking.  Twins John and George Kembel actually facilitate in stereo.  To watch and be a part of their combined effort was like drinking from a fire hose.

The event and the people were great fun to work with and pushed my limits on the overlap of design thinking and social thinking.  Working there really made me feel strong and I found myself in a flow most of the time.  It caused me to notice that I really love the expansion of design to design thinking. But for you and your agile teams, the innovations in team room furniture was really important. Creating a culture of innovation relies on creating the right environment.  If you have read Takeuechi and Nonaka’s book on Knowledge Management, you will recognize the concept of “Ba.” Ba is the shared space that creates context for the knowledge-creating company.  (See figure 4.3 on page 102 of their book for a cool illustration of the whole concept)

The d.school is full of flexible, collaborative space of all kinds, shapes and sizes.  They are constantly trying new things there.  Built for running multiple, parallel design projects in 15 week cycles, it is empathetic to extreme users.  The space is in its sixth iteration of the space.  Scott Doorley and Dave Baggeroer worked with George over the last five years to really make this place something special.   As a result of working at the extreme of rapid collaboration, they have come up with some fantastic furniture designs that you should consider copying for your team and meeting rooms.  Unfortunately, you can’t buy this stuff – you have to build it locally.

Here is a set of stackable and highly portable white boards.

Notice the Z-shaped foot that allows them to stack and move around corners.  These ideas came from retail stores.  Also notice the red peg in the whiteboard.  This is designed to hang portable whiteboards that you can take back to your own space.   It could also hold a pad of flip-chart paper.

This line is where they store the student efforts.  Notice how the hanging whiteboards are stored.  It is easy to imagine collaborating in another person’s office and then bringing the whiteboard back to your office without using tons of flip chart pads.

Below is a portable wall system built with spring-loaded feet to allow you to make semi-transparent or opaque walls by lightly snapping them into place.  You can see them used above to make the line where student’s store their work.

These cool pommel horses, pictured below, make great furniture for a team collaboration space.  You can sit, stand or work at the structures and they force you to not think in hierarchies:)

Finally, don’t miss the d.school’s blog and the coverage of their sugar cubes.

I hope some of these pieces of furniture compel you to try some new furniture in your space.  If you are not quite sold, you might read Tim Brown’s new book “Change by Design.” It is a great living example of the approaches that IDEO and the d.school use to create empathy, insight and desirable design in physical, virtual and social systems.

Do you have any experience applying design thinking in your agile teams?  Jared Spool’s talk at Agile 2009 was a great example of applying design thinking to software.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

I often hear questions from Pivotal Tracker users about how to organize teams and projects. We also see many requests for features that would make it easier to see stories from across multiple projects.

Tracker is designed for full immersion in one project at a given time. This stems from how we work at Pivotal Labs.

We organize teams such that a single team (and the people on that team) have a single backlog (and Tracker project). This means that within a team, there are no conflicts in terms of priorities, there is less context switching, and the team is completely focused. It leads to more consistency from iteration to iteration and therefore a steadier velocity, which allows you to have a more accurate insight into how long the rest of the backlog (or a release) might take to complete.

We also make it so that anyone on a given team can grab the next available story from the top of the backlog (or the current iteration). This implies few or no specialists (there is no back-end guy), and is generally referred to as collective ownership. It increases overall efficiency by allowing the team to dynamically re-balance, and minimizes reliance on any individual person (which among other things, leads to more relaxing vacations for developers).

The project's customer (or product manager) focuses on prioritizing stories in the backlog, and the development team is collectively responsible for delivering software based on the backlog.

We use labels to tie related stories together within a project. These can represent a major feature, specific end customer, etc. Labels can help answer questions like, how much work is left in this large feature?

A single backlog for the entire team does put more work on the plate of the owner of the backlog (customer / product manager), as he or she has to constantly make potentially difficult prioritization decisions, but, thinking hard about priorities is a good thing, and it allows the development team to focus on getting more work done. That ultimately makes everyone happier.

Also, there are people in certain roles (for example executives and designers), that given their nature, tend to be involved with multiple projects at once. Tracker could certainly use some features to help these roles, and we're thinking about these, but overall, it's more oriented towards enabling the immersed team.

A single team/project can get large enough to the point where it becomes challenging to manage a single backlog. For us, this point is generally reached with 5 to 6 pairs of developers (or 10 - 12 people). Assuming that more developers can actually add value to the overall project (this is not always the case), it's probably worth considering splitting the team into multiple smaller teams, each with their own single backlog.

To avoid knowledge and cultural silos with multiple teams, we find it helpful to rotate a few people around teams every iteration. It's important to maintain consistency (and therefore a steady velocity), so you don't want to shift too many people around too often - usually rotating just 1 person (on each team) each iteration is enough, assuming you're pairing and switching pairs within each team often.

In a multi-team (and Tracker project) environment, the product/project manager acts as a load balancer, and allocates work across the multiple teams/backlogs by considering velocity, dependencies, etc. This is typically a full time job. Tracker doesn't have much out of the box to help with this, but we're thinking about this as well, although it may be that some of this kind of work is better done in a spreadsheet, or other, more traditional project management tools. (As a side note, we did recently add the ability to move stories between Tracker projects, making things a tiny bit easier for people who manage multiple teams/projects).

I'd love to hear your thoughts on any of this, including suggestions for how to organize large projects and multiple teams (and how Tracker can help with that).

I saw an interesting blog today by Bill Wake called "Scrum is a Silver WHAT and you want to put it WHERE?" where he makes the pithy statement that "Scrum is not a silver bullet – it's a silver mirror." Now I definitely think this is a good blog and recommend you read it. However, I must admit to having had two simultaneous reactions to it – and realized it epitomized my...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Pivotal Tracker is moving to a new private cloud hosting environment at Engine Yard this Thursday, July 22, starting at 8pm PDT.

Planned downtime is approximately one hour, but because we're changing IP addresses of the Tracker servers, it may take longer for DNS changes to full propagate.

If you've opened your firewall to a specific IP address for Tracker integrations, you'll need to make changes. We'll post the new address of the integrations server after the move, you can also 'ping api.pivotaltracker.com' to resolve it.

Apologies for the inconvenience, we're hoping for noticeable performance improvements in the new environment.

Pivotal Tracker is moving to a new private cloud hosting environment at Engine Yard this Wednesday, July 22, starting at 8pm PDT.

Planned downtime is approximately one hour, but because we're changing IP addresses of the Tracker servers, it may take longer for DNS changes to full propagate.

If you've opened your firewall to a specific IP address for Tracker integrations, you'll need to make changes. We'll post the new address of the integrations server after the move, you can also 'ping api.pivotaltracker.com' to resolve it.

Apologies for the inconvenience, we're hoping for noticeable performance improvements in the new environment.

Dear Readers,

Writing or receiving a break-up letter can be fairly daunting or shattering, depending on which end of the letter your name appears. That letter puts a pretty hard stop to a relationship. It’s communicating detachment and finality. It can create a lot of pain whether intended or not. In contrast, a love letter is uplifting. The endorphins fly! Someone is revealing their attraction for you, and their hopes and wishes for a future with you.

Now, there is a reason I have these letters on my mind. I’ve just returned from Rally’s Agile Leadership Forum – a great gathering of people eager to lead successful Agile transitions in their organizations. The event included a lively presentation from Forrester Research’s Senior Analyst Dave West: “Agile Adoption – Research Findings on the Adoption of Agile.” (You can find some of Dave’s data in the “Forrester Wave: Agile Development Management Tools, Q2 2010″). We also enjoyed an inspirational talk from our CTO Ryan Martens, called “Moving Agile Beyond Software.” These great presentations were followed by breakout sessions and a panel discussion about Agile challenges. Now, how to end the event?

As emcee of the forum, I not only kicked off the event, but it was my job to bring closure to the gathering as well. How can we have people walk away with thoughts about Agile? Why are they interested in the first place, and where do their concerns lie?  I was inspired by a video I recently saw about “breakup letters.” The Breakup Letter is a design research tool that Smart Design uses to understand the emotional connection between people and their products, services, and experiences. One person broke up with his cell phone, another, her single-cup coffee maker.

Now, just how does this relate to the Agile Leadership Forum? I liked the concept of the breakup letter, but I decided to entirely flip the idea and close the event by asking everyone to write love letters instead. In the spirit of Cyrano de Bergerac, I asked each table of participants to work together in crafting a “Dear Agile” letter. In this letter, they were to convey their attraction to Agile. And, they were to reveal where they were concerned about as well. All letters were to be from a secret admirer :-)

Once the groups began to read their letters, I knew we were on to something. Though I don’t have the reading of the letters on video, here are a few examples of our “Dear Agile” love letters.

 

Run this exercise in your own group to find out what the Agile “lure” looks like and also what the “turn-offs” might be.

Breathlessly awaiting your comments,

Jean

p.s. If you want to read some of the transcribed texts of the love letters, read on!

__________________________

Dear Agile,

I have admired you from a distance for some time. Waterfall and I are in the process of an ugly breakup. There is so much about you I need to know. My friend says great things about you. You are so simple and straightforward– no mind games like Waterfall.

This won’t be simple. Waterfall still has clothes at my place. My Facebook status is confused.

In the relationship as we get to know one another, we will have to know each other carefully– co-locating right away? Are we sprinting too fast?

Be gentle with me.

Looking forward to a rapidly developing future.

xoxoxo,

Secret Admirer

__________________________

Dear Agile,

I love you because you offer quick cycles, better quality, and better teamwork. From the first time I saw you, I thought I could begin saving money and add business value.

But, fair Agile, you are not so simple. I’ve heard you are a micro-manager. I don’t totally understand you. Some people are confused by you. On the surface, you sound so perfect and simple, but the more I get to know you the more questions I have.

But, among all my choices, I choose you. You promote collaboration, and allow me to turn things around quickly. You’ve helped me trim weight and stay lean. Don’t disappointment me, I trust you!

With all my love,

Megedá

___________________________

Dear Agile,

I loved you from the first moment I saw you, I loved your fast, speedy releases and that you don’t come with a lot of baggage or documentation. You’re simple and down to earth. You are a great communicator. I always know where you are and my friends love you, too.

I am, however, a bit concerned that not everyone accepts our relationship. I am worried that as my job continually grows and my needs scale up, whether you can handle the increasing challenges. And I’m concerned whether I can afford you… Our relationship and your attachments are what intrigue me the most.

Looking forward to spending more time with you and getting to know you better.  – Your secret admirer.

___________________________

Dear Agile,

We love you, we think you are awesome – for the following (bulleted) reasons:

• Agile accepts changes and encourages frequent changes
• Agile can start implementation before full requirements are known.

We do however have a few problems with you agile –

• Handling cultural change in the organization
• Does not solve all our issues
• Makes distributed teams harder to work with

- Your secret admirer -

Chat is back.  Just add a Chat tool, and click on the tab to drop into the chat room.  The new chat tab will be useful because:

Everyone on your team can use it.  It has the correct permissions for each team member, it requires no client software, and it is usable with any modern browser.  It gets messages with HTTP "long polling", so it reaches through firewalls, even proxy firewalls.  This is an important upgrade from our previous chat implementation, and it is especially important for workplaces where Skype is banned for it's bandwidth grabbing, firewall tunneling tricks.

Searchable history.  So, for example, your new team members can go back and find that reference URL that you posted last month.

Convenient linking.  It links to the user profile of the people in the chat room. You can link to ticket 99 with #99. You can upload files and get links and thumbnails.

It shows team activity in one river of information.  You can optionally edit the settings to show team activity - like commits, messages, new and edited tickets - in the chat message stream.

This is the first big win for our bounty program.  We thank D3velopers, an outsourcing company based in Pakistan, for implementing this feature.  They had some previous experience with COMET chat.  They were willing to do research on our preferred server (Nginx).  They were flexible in improving the feature, and delivered on time.  I hope that we can do more of these bounty projects.  Note the "Powered by D3velopers" logo on the top of the "Who's Chatting" column.  If you take responsibility for a tool through the bounty program, you get paid, and you get the logo and link.

Our previous chat implementation had a poor communication protocol that prevented it from working through firewalls.  We let it linger as a quality problem because there are many alternative chats, such as the popular Skype conferencing.  However, we received more and more questions about chat over time, and I am happy now that we have this solid new implementation.

Technology Credits As usual, we rely on great open source software provided by others.  The technology stack includes the Nginx HTTP Push Module.  We use Nginx in our proxy servers, and we found it to be fast and reliable. The Push Module is a "beta" feature, but it has served us well so far.    We use Xapian text indexing and search, and of course, Ruby on Rails, MySQL, and the whole Linux stack. The D3velopers team used our tool development kit to generate a new tool, and wrote javascript to finish the client side implementation.  We learned  something about playing sound - the little chirp that the browser makes when you get a chat message.  Browsers got quite confused when we asked them to play a sound, and they stopped taking data entry, went to load quicktime, and did other bad things.  Fortunately, the author of Soundmanager2 figured out how to use flash, with a fallback to HTML5 sound features, to play sound reliably.

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";

Matt Phillips is a Senior Project Manager who has spent the last few years helping shape the Agile development process at Lulu.com. He currently heads up the Lulu Project Management Office and has spent several months setting up Agile practices in Lulu’s India office, based in Bangalore. In advance of his executive panel discussion at Rally’s Agile Success Tour in Raleigh, NC, we sat down with Matt to ask him 5 questions about Agile.

1. How have you implemented Agile across your organization?

We’ve rolled Agile out among all of our distributed teams, which are located in Raleigh, NC, the Ukraine and India. The time zones have historically been a challenge, so we had our remote teams spend several weeks in the Raleigh office working through daily Scrums. Now, they’re essentially as included in the process as possible. We use video conferencing for daily Scrums and to schedule iteration planning. All the teams collaborate to define stories, determine velocity, and plan iterations. We use Rally to make projections, track our velocity, and get visibility into the health of our projects. The metrics have become indispensible for judging how we’re doing, making accurate projections, and delivering upon our commitments.

2. What was your #1 reason for adopting Agile development?

Lulu adopted Agile at a point where the company was very much in start-up mode. The ideas were coming at a frenetic pace and the engineering team size was poised to expand. Agile methodologies were a good fit for Lulu’s culture and environment. The concepts of short iterations and regular release cycles paired with Scrum provided a quick time-to-market period for new ideas. At the same time, by adopting Agile methodologies, Lulu gained increased insight into the development team’s progress and performance as the team grew and feature sets became more complex.

3. What has been the biggest benefit of adopting Agile?

The metrics and amazing visibility we have into development projects. This is especially important for a team that’s 9,000 miles away. We have visibility into how they’re progressing on features, what’s coming next in the roadmap, and really flushing out what the product backlog looks like and where we’re headed.  Prior to implementing Agile, it was very hard to sync-up  (because of the 9 ½ hour time difference), maintain a feedback loop and foster collaboration with teams so far away.

4. What one piece of advice would you give to new Agile teams?

My advice would be to ease into it – kind of like steering a cruise ship, not turning on a dime. Start with familiar concepts and gradually introduce Agile practices over time. We started with familiar ideas like release dates, associated task lists, estimations, and tracking criteria. Then, we used a phased approach to introduce the concepts of iterations, story points and relative sizing, velocity, and ranking. We continue to work toward more granular inputs to smoothly coordinate roles, tools and dependencies within Rally as we go along to continuously perform at higher levels and get better outputs.

5. How can you tell that Agile is successful at Lulu.com?

One of top ways I can tell that Agile is successful in our organization is that people, even outside of engineering, are speaking in story points. That tells me that Agile has really taken hold. Using story points and velocity for our release planning makes it easy to arrive at a date that everyone is comfortable with. On top of that, our track record since adopting Agile shows that we’ve been delivering on our commitments every time.