Living Agile: 90 Day Action Plan

So, in breaking out of the post summer slump, our board at Twin Technologies had the executive team create 90 day action plans. I posted mine, and was surprised at how comfortable it was to create. Then, it hit me.. 90 day action plans are just a form of Agile planning.

I've always kept lists of tasks on 3x5 cards as well as various text documents that become intertwined over time. Whenever I start to feel like I am not focused, I return to the cards and find something that seems high priority to me. As a Scrum Master, the correct path should have been obvious, but sometimes we are blinded.

A 90 day action plan is simple to create. I used a Google Docs spreadsheet as my platform:

1. Create a new spreadsheet
2. Create two tabs - Goals and Actions
3. List high level goals you feel you can accomplish in the next 90 days on the goals tab
4. Prioritize these goals
5. List high level actions for goals
6. Create small action "tasks" for actions you plan to work on in the current week
7. Track status (%) against done.

In each goal and action there is an identifier so I can reference between tabs. I also have a column for marking predecessor tasks. You'll notice that this is very similar to a typical Scrum project:

1. Create backlog
2. Prioritize backlog
3. Estimate high priority stories
4. Determine what stories in the backlog can be tackled in the next sprint
5. Create tasks for accepted stories and give detail estimates
6. Track status (%) against done

The same benefits exist:
1. Ability to point to what goals suffer if other goals become a higher priority
2. Ability to self organize
3. Detailed reports can be generated against status daily
4. Reprioritization and goal changes are encouraged and expected

These are just a few. It took me about 30 minutes to create my 90 day action plan, and I encourage you to spend 30 minutes trying it out as well. I find myself more focused and really getting things done!

Agile: I think a Chicken just ate my Pig

Check out my SlideShare Presentation:

Agile: I think a Chicken just ate my Pig

View more presentations from ntunney.

Mixing it Up: Defining the Corporate Solution

At a high level, solving the corporate issue can be accomplished by performing the following:

1. Identify what networks to monitor initially
2. Define what criteria makes a node the most influential for each network
3. Identify the most influential nodes within each social network
4. Identify which nodes belong to more than one of the networks
5. Also, allow an entity to define what networks have more weight than others
6. Rank each node according to influence across entire set of networks

The end user perspective is a bit more challenging but necessary since this is the dataset we need to crunch to perform the aobve. I will begin to tackle that in my next post.

Mixing it Up: End User Perspective

In continuing my open source social network project transparency theme, I'm going to post two perspectives with several use cases. The first perspective I'll post is the end user.

As a user of multiple social networks that understands that there exist tons of other networks I currently do not belong to, I have a hard time deciding where to spend my time and effort. The two I use most heavily are Twitter and Facebook.

1. Twitter - Allows me to connect with my followers on mostly non-personal conversation, instructional items and interesting tidbits as well as find others with similar interests.
2. Facebook - Allows me to connect with trusted friends and colleagues and post personal comments and updates.

These networks take time and effort to upkeep and there may be great social circles I am missing out on just because I do not know I already have a following on them which would allow me to test the waters without having to invest time building up a circle of followers.

Currently, I can import contacts from other social networks and online services, however, until I create an account I have no idea.

User Stories:

• As an end user I want to be told that a friend in one social network belongs to another social network that I am a member of so that we can connect in multiple mediums.
• As an end user I want to be told that a friend in one social network belongs to another social network that I am NOT a member of so that I may join and connect in another medium.

Understanding User Stories

I recently had a co-worker ask me the best way to go about creating user stories, so I pushed them to a presentation by Mike Cohn. The presentation listed the framework to be applied as well as some theory. The response was "Yeah, we know all that. How do we get the Product Owner to write the stories, or how do we help them write the stories?"

This got me to thinking and after an hour long conversation I think I have some ideas to share:

1. Scrum Product Owner Training is a must, but not always feasible depending on the client environment.

2. Don't expect to hand off the process to your Product Owner. Explaining the process in detail might excite some clients, and be off-putting to others.

3. Before the Product Owner and the Scrum Master know how the other works, I find it easiest to start with Feature Groups and work them down into user stories one at a time. Feature groups define the higher level items that exist within your project/product. Each Feature Group may then be tracked to show progress against requested functionality. Starting at Feature groups allows the Scrum Master to get the ball rolling and soon the stories will flow faster than you can write!

4. Don't Talk Tech! User Stories should be written to solve the 'What' and even 'How', but are not meant to define the underlying implementation. In most cases tasks will define the implementation.

5. Make sure the Product Owner and Scrum Master have time alone to prioritize the stories. Bluesky sessions with the extended team are very beneficial, but block progress on prioritization.

6. Ensure your Product Owner is empowered. If they are not empowered, the user stories process will fail. Prioritization will be undermined. Use the transparent nature of Scrum projects to determine and call out risks with the Product Owner.

7. Especially early on, write the user story framework down and refer to it often: 'As a ____ I can ______ so that _____.' Don't forget the 'so that' as that becomes imperative in the ongoing prioritization process as well as provides clarity for the team.

8. Don't insist that the Product Owner speak to you in user story form. Take notes as the Product Owner talks and then work with them to write the official stories. The process will improve as iterations pass.

Hopefully this helps someone out there who is struggling with a client who is new to Scrum, or who is having a hard time getting the juices flowing!