HSG Consulting - Personalized Solutions for Business Growing Pains

In some situations small incremental steps are best to adopting Agile. I’ve found these three small steps can send you on your way into Agile. You’ll notice a trend.

1. Daily stand up meetings. Those short meetings where every team member stands in a circle and reports on what they’re working on and what roadblocks they are encountering. Getting everyone together once a day to share what they’re working on and what roadblocks are in their way is a great way to begin to build an Agile team.
2. Agile board. Posting the story cards in a visible location and enforcing the status indicators (yellow, green or red adhesive dots) is a powerful tool in raising the team’s awareness of the weekly schedule and progress.
3. Team Planning Sessions. Planning as a team is a powerful productivity tool. As the developers, business analysts, and product managers gather together and discuss the goals for the iteration and the ensuing tasks, the team takes ownership of the project plan instead of the lone project manager. With the team’s commitment to the plan, the project manager now can work for the team by removing roadblocks and providing support as needed.

That’s right, the key items are focused around forming teams. In an Agile environment it is the team that builds success. The best way to begin to see the impact of Agile is to start forming, empowering, and supporting teams.

What convinces me about these 3 simple steps is that I’ve seem these work in non-Agile organizations – and have seen first-hand the benefits of teamwork. We’ve known this for years in project management, with organizations focusing on team building exercises and excursions, team guidelines, and the like. It is that Agile takes these principles and provides a framework in which to consistently apply them. Simple concepts like team members sitting together, all the time, not just during critical project junctures; team planning, all the time; daily team communication, all the time.

It’s one of the things I like best about working with clients, helping to set up the structures for teams and seeing the teams form and grow. Kind of like gardening, where with the right materials and environment wonderful things can grow! Maybe that’s why I also like gardening so much

Recently I facilitated a meeting of local officials here in Ann Arbor. They were members of the Local Development Finance Authority (LDFA) board, charged with oversight of the state funding to the Ann Arbor and Ypsilanti Smart Zone that spurs on high-tech business growth. This volunteer group operates openly as a local governing body, and as such, must run their meetings according to Robert’s Rules. As such, this group has a strict meeting format and structure and is open to the public. Can collaboration be achieved and trust built among members who meet infrequently in a structured and public environment?

I was thrilled to be asked to help run a workshop for this group as they tackled such thorny issues as revisiting their purpose and goals and refining the roles and responsibilities of the LDFA and their biggest supplier, Spark. Bringing in an outside facilitator enabled every board member to participate equally without concerns of bias or prior knowledge affecting the discussion. Geting the group to come together on ideas and plans was a key goal of mine, and the chairman of the board.

My plan was to start with a process to ensure everyone’s voice was heard. The LDFA has 9 official members and 3 ex-officio members. Anyone who’s worked with groups knows that the larger the group gets, the greater the impact of group dynamics – where quiet or more reserved folks tend not to share their thoughts as much as less reserved members. So while my intentions were to begin to pair members together to address issues (which has the additional benefit of increasing familiarity of the members and building trust), the public meeting rules requried that all discussions must take place in the open and heard by all.

A modest adjustment to this model had every member write down their thoughts on 3×5 sticky notes and one-by-one share their written notes and ideas with the group. These notes were then posted on a flip chart on the wall – capturing all members ideas in one space. As each member shared their notes with the group, the group asked questions for clarification. This portion of the workshop went very well. Diverse and broad ideas were presented and shared with the group.

These ideas were quickly consolidated by the board chair and a few members while the rest took a much needed break. The remainder of the workshop benefitted from the openness of the first exercise. While the structure reverted to a more traditional board meeting – dialog among the members – the tone and nature of the dialog gradually moved away from strained to more collaborative. Thes discussions were focused back on the identified purposes, which worked to guide the group’s deliberations. By the end of the session, tough questions were asked and answered, building a foundation for increased trust among the board members.

With the facilitated aid of a few structured exercises, meetings that are subject to the Roberts Rules structure and public scrutiny can be collaborative and engaging.

Lets talk about user stories. Writing and appropriately sizing user stories is one of the first and continuing challenges for organizations adopting an Agile methodology. While similar to requirements in characteristics, user stories require some special attention to get optimal results. Below is an example of a user story layout.

Keep these three steps in mind for your user stories:
1. SSMART
2. User Centric
3. Independent
1. SSMART
No, that’s not a typo. Like your goals, user stories should follow the same principles, plus one, Simple;
S – Simple. The user story should be a simple item of work, not a complex series of activities. This is the heart of breaking a complex piece of work down into a number of simpler pieces that can be accomplished within the chosen iteration length. For example, a user story of ‘write and send next eZine article.’ is too vague, non specific, and feels complex due to its lack of specificity and simplicity.
S – Specific. Your user story should be specific about what is to be done. An example is: ‘Write up 2nd eZine article, format it using same template as 1st article, and ready it for distribution by selecting a target mailing list.’ This describes what is to be done, and provides enough information to begin work on the task. Note how this also defines done for the user story.
M – Measurable. Once you’ve written the user story, be sure your project team estimates the effort. Whether you use story points, hours, or some other estimation value, the act of estimating the user story will help vet the SSMART items and begin to open the discussion within the team about the scope and intent of the work.
A – Attainable. Ok, we have to actually be able to accomplish the task involved in the user story. By doing this we also support the definition of done.  So writing a user story of ‘Achieve world peace’ is a worthy goal, but not very attainable for most project teams.
R – Realistic. Like being able to accomplish the user story, it needs to be achievable by your project team. Setting a user story that is far out of their reach will not foster success. There is more that can be said of exploratory user stories, and how to treat them and use them within a project. However, the bulk of a project’s user stories should be realistic and achievable by the project team.
T – Timely. The user story should be achievable within the iteration time frame, and have a time frame associated with it. This supports the Measurable aspect of the SSMART principle.
2. USER CENTRIC
User Stories are written from the user’s point of view and tell the story of what is to be completed.  While this sounds obvious, it remains a difficult area for companies transitioning from Waterfall to Agile. A key concept for the project team is to clearly define WHO the primary user of the site is. If you design for everyone, it will be usable by no one. You can get a quick overview of persona’s on Wikipedia, which will reference much of Alan Cooper’s work . An example of a user-centric story aimed at the primary persona for the site is: ‘Jane Doe can upload her resume to the website, as well as provide up to 3 meta-tags for searching and up to 3 external links.’
3. INDEPENDENT
Often overlooked, the success of Agile user stories is the ability to replan and reschedule the user stories as business needs change. Each user story should be as independent as possible to avoid entire blocks of user stories that must be completed together. This is one of the hallmarks of Agile, and one of the pieces that teams struggle with as they try to simplify and break down a complex task into multiple pieces.
Think broadly here, and consider using techniques like stubbing out database connections so a user story that depends on a database being created can still be completed independent of the database, and integrated later when the underlying structures are set up.

User Story Samples
Following are some sample user stories that I’ve used as a Project Manager that help illustrate some of the points in the article. Notice the green status dot showing that task has been completed.

You might ask, what does mobile computing have to do with project management? The answer is LOTS. Projects create and maintain a calendar of events. Keeping these synchronized with your other projects, business meetings, your personal tasks, and having them handy where ever you go is a very good thing for your sanity and your project’s success.

Currently I use iCal on my MacBook as my primary desktop calendar. I synchronize it to Google calendar via BusySync. I have multiple Google calendars, home, business, and social group. These all sync between my MacBook and Google. I do provide some sharing of my Google calendars.

Now, to get the calendar and contact information from my MacBook to my Windows handheld device (Motorola Q) I primarily use Mark/Space. However, there are some limitations:

• The sync must be initiated via Bluetooth connection on ActiveSync on handheld. Because Bluetooth sucks up my phone’s battery so much, I do not leave it on. So the sync starts with turning Bluetooth on, connecting with my MacBook, then starting ActiveSync via a Bluetooth connection to Mark/Space on the MacBook
• If I have run the browser from the handheld the connection doesn’t take the first time. I must reboot the handheld, which because it’s a Window’s device takes about 3 minutes to shut off and restart, then initiate the Bluetooth service, then start ActiveSync
• I can control where files come from on the MacBook; and this is my primary way to get files loaded nicely on the Motorola Q
• Interestingly enough, I can connect the Motorola Q to my MacBook via Bluetooth, treating it as a drive, and easily move pictures from the phone to the Mac. This is my preferred way to get pictures off my phone. Hmm, I should try it to get files ON my phone….

The second way to synchronize my handheld with my MacBook iCal is Google calendar’s Goosync. Notes on this are:

• It must be initiated on handheld by running Goosync
• It does operate over Internet- no Bluetooth connection needed. This alone saves me a step and potentially a lot of time since I don’t have to reboot the phone if I’ve run the browser.
• This can be automated by upgrading to the Premium account at 19.95£ annually
• The free version only does calendar syncing. To sync contacts I need to upgrade to the Premium account and spend the 19.95£ annually.

The social network Plaxo provides a synchronizing service between Google’s calendar, iCal, and Windows mobile devices. The Google calendar is free. Synchronizing to the Windows mobile device costs $49.95 a year – a bit steep for me. However, Plaxo’s calendar display is VERY NICE. The Upcoming tab has the best user interaction of all the calendaring tools I’ve used. See screen shot below. You see a three-week block view with clickable events to view the full text. Being a visual person, I like seeing the information in block form.
The most useful tool, however, is the information of what is coming up next. I get a gentle countdown of what appointments are coming up TODAY in the top part of the window, a view of what tomorrow’s appointments are in list form, and countdown to my own birthday (yeah!) as default, ability to add others, and the weather for my area today and tomorrow. The screen shows enough white space to make the calendar easy to read while providing all the information.

Mobile Me does not sync to Motorola Q. Only iPhone/iTouch and PC’s and Mac’s and of course the mobile.me website

In summary, I’m seeing more and more people using Google calendars as either a primary or a holding place, sharing them between families and social groups, and work project teams, and synchronizing these to their handhelds and desktops. The synchronizing tool is more based on what desktop and phone device they have (Mobile Me for iPhone/iTouch, GooSync, Mark/Space, Plaxo, and Blackberry sync tools for others). How are you keeping yourself synchronized?

Recently my oldest son graduated from High School with all the accompanying graduation parties and preparations that goes along with it. Now, for anyone who has gone through this, you may recall how involved all the activities were. Add to this running a business and trying to keep your own sanity, and you may find like I did, that I needed a system for planning the event.

I had basically two key projects to interleave, the graduation party preparations and the tasks of running my business. I started with creating a list of all the things I needed to do for the graduation party – see the below picture. As you’ll see, I made some attempt to assign dates to items to pace out the effort, and even began estimating how long it would take to do a particular task. The task list became unwieldy as soon as I wrote it. Immediately I wanted to move things around and see how well I could actually accomplish all this in the time allotted.

The second project of running my business would certainly impact my ability to get everything done for the graduation party. I now needed to task out the business project, and merge the two.

Creating the Plan

As you may know, I believe in keeping things simple and open to change using Agile-based tools. For the business efforts, I wrote down the item on a 3×5 card and estimated the effort it would take to complete it. I then laid these out on a day-by-day basis – creating my work plan for the business, as shown below.

Likewise, I began transcribing all the tasks from the grad party list onto either 3×5 cards or sticky notes, estimated them, and began interleaving them with the business layout such that each day was evenly loaded with effort. These were placed on 8×10 sheets of paper, where each sheet of paper represented a day, or one iteration. I now had a work plan for both projects.

Replanning
At the end of every day I would evaluate what got completed, as indicated by a green check mark, and what needed to move. Because as we all know, not everything goes as planned! Life happens, business needs change. Each day I got to re-evaluate what was key and what wasn’t. The daily review allowed me to re-prioritize the efforts to ensure that the key items would get completed, allowing less critical items to move to the bottom of the list.

Additionally, I found that some items, like Thursday’s ‘Purchase last minute items’ was complete enough to take to the grocery store and use as a shopping list. The tasks were more than just reminders, they were actionable items.

Team Involvement
I started to share with my family the tasks needed to be completed for the party by referring to these plans, and leaving them in a common space. The plan became visible.

Then a magical thing started to happen. My family not only started asking ‘what is on the plan that we need to do today?’, but they started looking at the plan themselves. They had begun to buy into the system, and take as much ownership as me on the efforts for the party. Sure, I could have just given them a task list, but I would much rather they buy into the effort on their own. Isn’t this what we want of our work teams? To be so engaged with the effort that they volunteer to work on items, and look for the next thing to do?

Yes, the party went off without a hitch. I even had enough time during the week to throw in some unplanned items, like handling last-minute business needs. Sunday came and I was not stressed out, everything that needed to be done was done without the usual last minute running-around and rushed feeling.

Wouldn’t it be nice to have this happen for all our projects? It can. Try these simple Agile project management techniques for your next project, and see the difference yourself.

I’ve been wearing my pedometer for longer than I’ve been actively tracking the steps. However, for the past month I have been logging my steps as part of the Commuter Challenge Walk Around Ann Arbor through WalkerTracker. Prior to logging my steps I would walk about 2,200 steps a day. Which is what caused me to set a goal of 4,000 steps per day – an admirable goal at about double my normal amount. But a funny thing happened, I started walking WAY MORE than 4,000 steps per day, my current average is now 7,500 steps per day. 

Nothing in my life had changed that would account for the extra steps. Nothing except the act of measuring.

A year ago I started Weight Watchers to lose some excess pounds. For those unfamiliar with their points method, you track and log each food item that you eat and subtract it from your daily allotment.  This gives you an on-going tally of how much food you can eat for the day. These are kept in a weekly tally, so you can see how you’re doing going over or staying within the alloted points for an entire week. While I have successfully shed those extra pounds (24 of ‘em) over the past year, I continue to monitor and log my daily and weekly points. Why?

The answer lies in the act of measuring and the impact it has on what you are measuring, and specifically on the behavioral impact of measurement. By measuring something you inherently focus on it, and improve it, even if the improvement is at a subconscious level. 

And what happens when you stop measuring those things, having successfully improved them? Don’t they go back to their original sub-optimal state? Why do so many dieters gain back the weight they lost? I venture that one reason is the loss of constant measurement and its impact on behavior. 

The act of measuring leads to a continuous improvement loop.  

Hmmm, so isn’t this true for Project Management as well? We improve those things we measure. Whether it is our estimates, our time to complete, the number of hours remaining, the number of tasks to complete. By measuring and tracking we tell our teams what is important to the project and its success. However, when we stop measuring, the items so often go back to their unimproved state. 

Well, we can’t possibly measure everything all the time! We must chose wisely those items that we want to continuously improve. Which has me thinking more about Kaizen and it’s influence on the cycle of measuring and improving a process or operation. What if projects were thought of as a way to continuously improve the process, rather than just meet that deadline or produce that widget? Wouldn’t the projects be considered far more successful in terms of value to the organization and ROI? 

Well, I’m up to 3,800 steps for today, I think I’ll go for a walk and think more about project Kaizen. I’d love to hear your thoughts on this as well. Post your comments to this blog.

 

 

I recently completed work with a client that was struggling with their move to Agile practices. They were transitioning from a traditional waterfall process to an Agile process for all their IT projects and were experiencing some difficulties in writing, estimating and planning with Story Cards.

Their most obvious issue was that their Story Cards were not on cards at all, they were documents stored on their corporate Sharepoint site. By that very nature, they were able to write as much extraneous information as they could type. Remember, they were moving from a traditional waterfall process, so many of their business analysts and project managers were used to formal requirements documents. The new user stories as they called them became amalgamations of requirements, functional specifications, ideas, and anything else anyone said about the user story. Being stripped of their traditional documents the teams were morphing the Story Cards into a catch-all for the functions.  No wonder they were having trouble with estimating and planning!

What to do?
I started with first providing training on user stories to their Business Analysts and ScrumMasters. The sessions were geared to focus on their specific issues with user story writing. Examples of good and poor Story Cards were provided, as well as hands-on experience with writing Story Cards. Real-life examples were pulled from their Sharepoint site for examination during the training sessions, and used as discussion points for reworking their existing User Stories into better formed Story Cards.

Light Bulb Effect
One of the most notable items I observed there was the impact of business analysis practices in an Agile environment. Any deficiency existing in business analysis practices or skills among the Business Analysts becomes highlighted in an Agile environment. When writing Story Cards, the Business Analyst must produce a clear and concise picture of the value of the task to the end-user. This story covers describing the setting in which the end-user would be performing the work, the Why, along with Who will perform it, and When it would be done by the end-user. I call this the Light Bulb Effect – when the spark of an insight or idea occurs to the Business Analyst and this is transferred to the development team by way of a well written Story Card.

During the annual work holiday party at our house this weekend (yes we know it’s well past the holidays) I experienced some awesome and unconventional team building. My teenage sons ran out and purchased Rock Band for our Xbox 360 system and set it up during the party. Suddenly we had 4 people of varying ages and backgrounds playing and singing together.

The basic premise of this game is to live your alter-ego and play a pseudo-musical instrument and sound reasonably well. Hooked up to your TV (the larger the screen the better!) you see your colored symbols for notes stream towards you, while the accompanying music of the song plays in the background. If you miss a note, a slight off-pitch note plays, if you hit the note, the song plays as normal.

Unlike similar games such as Guitar Hero, your goal is to play with others as a team. A guitar, bass, drums and singer can all join in together for each song. Each player can play at their level of experience; Easy, Medium, Hard, Expert. But each player can fail if they miss enough notes. If a player fails, they increase the risk of the entire band failing the song – which ends quite abruptly among clanking sounds and boos from the virtual audience – not to mention the abuse from their physical band mates! Each team member has the incentive to play well to not only stay in the game themselves but to keep the band going and succeed.

So, during this evening of physics nerds, spouses, friends, and children at our house, I saw frequent examples of others stepping up to save the failed player. How does a simple computer-based game bring such diverse people physically together to achieve a single goal – where all the office ‘team building’ seminars continually miss the boat? My thoughts on this are:

First, the game appeals to a wide range of people. It’s rock & roll after all, using tools that are familiar to many of us – guitars, drums, a microphone. To play is simple – you need only a small amount of instruction before you’re rocking with the rest of the band.

Second, the physical nature of the game ties into our human nature of binding together in person. You’re sitting together in the same room, and if you’re lucky, you may have others watching you play as well. Which leads me to #3…

Third, you’re up on stage, both virtually on the TV screen, and physically in the room, while others can, and will, watch you. Who doesn’t enjoy being admired by others???!!

Fourth – it’s just plain FUN!! No wierd exercises or quirky exercises to complete – you just start playing and having fun right away!

In short, the next time your team needs a kick start for some team remediation, use Rock Band and you just might actually have some fun!

ps – anyone willing to get a Rock Band jam going at an Ann Arbor business, let me know. I’ll bring my own guitar!

Just finished the 1,000 page novel by Ken Follett, World Without End. Set in mid-to late-1300’s England, it traces the lives of 5 individuals from childhood to old age. Facing adversity, apathy, hunger, torture, abuse, and worst of all, the bubonic plague, Ken Follett brings the past to life in a very realistic format.

Through the key characters, Ken shows us that no matter how difficult, we must deal with our problems, face our fears, and above all, remain true to ourselves. While tied up maybe a little too neatly, the story does present a view of the everlasting nature of life. The ending is more of a life goes on routine than a denouement. While half of Europe’s population is devastated by the Plague, those that were immune or recovered from the ravages of the virus were the strong ones that carried on. The title is taken from a Catholic psalm: ‘Glory be to the Father, And to the Son, And to the Holy Ghost. As it was in the beginning, Is now, And ever shall me, World without end.’ And indeed, the story ends with exactly the feeling that the world is everlasting, despite the effects of people and disease.

We see the beginning of the Renaissance in the 40 years of the novel – Caris (a woman who wants to be a physician but becomes a nun to escape an indictment of witchery) ushers in a new form of medicine that relies not on understanding the humors of the body and bloodletting but on observation, deductive reasoning and rational thought. Her lover and finally husband, Merthin, brings glimmers of new architectural understanding to England’s small communities with innovative uses of cranes, octagonal topped structures, cofferdams around bridges, and again the use of deductive reasoning to understand the nature of buildings and their strength.

A great historical read, one that brings the past to life and feels all the more contemporary despite the passage of nearly 700 years.