Strengths of a ScrumMaster

In previous posts, I listed some introductory material on strengths and how to start the process of beginning to build a strengths-based agile team. The next deeper and more powerful step in the process is working with team members one-on-one through the lens of their specific strengths.

When speaking at events, or after facilitating taking the profile test and walking through the results, I am often asked "What strengths do good ScrumMasters have?" I think there could be a good number of different strengths, depending on how the individual leverages them, the make-up of the team and projects needs and the surrounding organization. I'll list several that I think are good or that I've seen leveraged well. I've also listed strengths that "pair well", balance and support, that strength. These could be other strengths that individual has, or strengths that other team members have. In the latter case, those team members need to be interacting and working closely enough together that those strengths come to play directly and collaboratively with the ScrumMaster. I think that a strength not being leveraged specifically when it's needed is like the superhero not responding to the call.

Some Strengths of a Good ScrumMaster
Belief
Belief is good for several reasons. One, I think believing in something, truly believing in it, is infectious. It spreads. Other people can't help but catch it, find out about it, get interested in it when they're around people who are staunch believers in it. Also Belief is great for ScrumMasters because people will surely have good questions, raise tough issues and even come against you. Your rock solid Belief will handle these, and often people need to see there is something real beneath what they see as the latest business fad or self-serving or just not well though through (which in all fairness does happen in our workplaces ). And sometimes it's only your belief in something that carries you through the hard times. And we all know that doing Scrum, and adopting agile in the bigger picture, can be quite difficult.

Pairs nicely with Woo so that you're winning people over to what you believe, and also pairs well with Leaner and/or Input so that you are always taking in information that fills out and supports your belief. That way you can engage in informative dialog rather than "because I/they/boss/Santa Claus said so, that's why" belligerent debates. Also, Learner/Input will broaden what you believer in, so that you become just as much a true believer in, say, test-driven development or continuous integration, as having retrospectives.

Futuristic
Another strength that can pull you through the difficult times and challenges is Futuristic - the ability to really see what could be. That vision should, of course, be shaped and defined by Scrum and agile, and related areas, so it also pairs well with Learner and/or Input. But where Belief is contagious because it provides a solid rock, Futuristic is contagious because it pulls people forward, positively, toward the vision. This is effective in good times and bad, because you can always move forward, ahead. To say Futuristic is important for leadership is an understatement because people, and especially teams, want to get behind, support and follow a vision. Paint that picture you see (cast the vision) repeatedly because vision does leak - life gets in the way and distracts people.

Input
Input is great simply because there is so much to learn, and to quote S.H.R., "it's great to learn, 'cause knowledge is power." As the ScrumMaster understands what's happening at a detail level in his team (with the QA tests, with the designers dealing with the outside vendor) or his company (with management decision making process, and new market they are consider) or with agile (the best books, good blogs), all those bits of information are fuel for good decisions at some later, who-knows-what time. Some people are good at listening and collecting information, but only when they know (or think) it's important information or an important time. As humans though, we make mistakes in judgement (such as what we deem 'important') and timing, much less simply missing information. On top of all of this, frequently it is the most specific details that have the truest value - such as the difference between getting an error versus no response on the call, or there's a new open source CI tool, or which server the problem was on, or that the newest version of the Spring framework coming out in five days can consume XHTML natively (I made that up). But the wonderful thing about Input folks is that they can't turn off the collecting machine. And as a ScrumMaster, this strength can be grown to take in all these great details all the time, every day from every team member and then, like a pollinator, carry it around to other teams, stakeholders, and resources to help them: make better decisions, solve problems, collaborate, raise the bar, help YOUR team.

Input pairs well with strengths that give it guidance and/or limits. Otherwise, the Input can be on the web gathering information for hours. And hours. And hours (trust me, I know this…). So, good with Deliberative, Maximizer, Activator, Achiever.
When paired with Relator, it might yield someone who likes to learn about others, which makes everyone on the team feel loved. Not a bad thing. Input also feeds Belief and Futuristic.

Maximizer
Going from good to great, that's the Maximizer. If you don't think you're group is even at "good", then consider that the fact you are there and know what you know means they are already better than they were before. That's good. Striving for excellence will propel you and the team forward through whatever means you have, whether forming allies, relationship, or using the other strengths you have. Watch that you don't get discouraged because the goal is so far away or hard to reach. Don't become frustrated with others who don't "get it" that we should do X, Y and Z (obviously!). Break down your goal into smaller, attainable pieces. Limit your work in progress to perhaps only focus on a couple items, areas or people. Learn to look for, and celebrate each step towards those.

Pairs well with some form of getting information in order to know what "best" is. That could be Input, Learner, Relator, Harmony, Empathy, Connectedness.

Relator
In the end, it's all about people, and here's where the Relator is powerful and effective. It the personal relationships that the Relator will form that will influence others to come to the meetings on time, try the new method of writing tests, be willing to hear out the person they're frustrated with, get management to agree to pay for the celebration meals, get the Product Owner to show up at the daily stand-up. More than that, though, the Relator is able to see what's in people that is causing them to either impede the agile adoption, or even just personally holding themselves back on the team. When we're running around dealing with people problems (and it's said that all problems in software are people problems), often the "issue" isn't the issue. For example, the problem isn't that testers don't have enough time, it's that the QA Manager hasn't been walked through the new approach slowly enough that he fully understands it and knows that the change isn't really a risk and that nothing bad will happen to his people (making him a bad manager, right?) or upset them with the changes so much that they are all freaking out and giving him more of a headache than it's worth (i.e., it would be easier to stonewall you with "problems" and "risk" and "process"). But imagine the change when he knows you genuinely care about him, how he does, and you understand that he has a team to look after, and that you want him to do a good job at that, and you have his best interests at heart, and will be there if there's any problems, questions or just to help. Wow. He can step forward now, even without all the answers. Even knowing there will surely be some issues.

In every problem and discussion that adopting Scrum brings about, or each new project, or even each new sprint, Relator comes to bear. Being present. Listening. Caring. Connecting. Which is to say, investing in others. And all those investments are money the Relator can borrow when he needs help, an extra effort, grace, trust, the benefit of the doubt, willingness.

Relator pairs well with those strengths that would shape and direct it. Otherwise, it can just sit there being "present" with anybody and everybody, not helping anything move forward. Maximizer, Strategic, Input, Learner, Deliberative, Futuristic, Restorative and perhaps the other feeling strengths Empathy and Harmony.


There are some other strengths that I will add later and update this same post.
Technorati Tags: agile, scrum

Starting Strengths-Based Teams

My most common approach to starting teams on a strengths-based approach is relatively straightforward, but powerful and a big return for a small effort and investment of time.

I order the StrengthsFinder 2.0 books, one per team member, on Amazon. Once the books arrive, I hand them out in the next team meeting (perhaps after the Daily Stand-up). I explain that the book is not so much to read, but for reference and that really it's for the code in the back of the book that lets them each take a strengths profile exam. The book has all the instructions on how to create an account and take the test. I ask that they take the exam within a week and to send me the results of their test.

I then schedule a 1 to 1.5 hour meeting to occur several days after their week deadline. In this meeting I give some background of the test, Gallup and why this is valuable to them. You can find this information on my blog or on the web. The main part of the meeting, though, is that I whiteboard a large grid. One by one, we go around the room with each person saying what their strengths are. I write them up and talk about each each, one by one. It's informative, fun and bonding.

After the meeting, I scribe the results grid and put it somewhere public (SharePoint team site, wiki, email it out, or posted in the war room). Depending on the team, I'll ask them to post their list on the cube wall.

All of this takes maybe 2 hours of effort, planning and meeting time, plus 45 minutes of their time at most to take the test. The logistics of doing this is very easy but has a huge return. But there's much more that can be done to leverage the value here, as well as grow it. I'll cover more of that in a subsequent post.

Technorati Tags: strengths, teams, agile, management, teambuilding

Introduction to Strengths-Based Teams

Over the last several years, when I work with agile teams, new or old, I have them take the StrengthsFinder assessment. I have found people in the Agile, Scrum, lean and XP camps who feel strongly about different aspects of how the work in our area is done. I feel very strongly about strengths, and would never work with a team without requesting they participate in the assessment and the training and guidance I wrap around that.

I have spoken on this topic from various angles for over three years, have used it with over a dozen teams, overseen over 100 assessments, read three books and parts of three others on the topic. I know it fairly well, believe in it, and want others to hear it.

I'll be sharing more on this topic this month, but for now let me share some introductory links of several videos from different perspectives, reference material and my own previous reference material.

Great video from Marcus Buckingham on strengths, how few of us play to our strengths, and myths that lead us away from our natural strengths.
http://www.youtube.com/watch?v=hWZTdso2Njs

Overviews and handouts from talks I've given or submitted, and other posts on strengths-based teams and management.
http://scottdunn.blogspot.com/search/label/strengths

Great interview discussing the business reasons and they share about their own strengths with good practical examples from Tech Ranch in Austin. They provide training for entrepreneurs, and has every person they work with take the profile.
http://www.youtube.com/watch?v=3wWIUu5fSlA

There are also now formal strengths-based programs at Baylor University and Azusa Pacific University's Noel Strengths Academy for Strengths-Based Leadership and Education. There's also a good overview video here - http://www.youtube.com/watch?v=UqKCUmsZKQA


agile, strengths, management,Scrum

My Work Manifesto

I've found that people can play in the same field, doing the same activities, even using the same words, but have vastly different motivations underneath. What motivates us isn't always openly discussed, but it's clearly evident when when I'm in a discussion with a new friend, some colleague my area of work, and I feel a connection on a deeper level. This becomes more of an issue when a business sector is having success and some come into that area simply for that reason. That is, most people I've met in art or landscaping do so because they are passionate about it, not because it will pay for a home in Newport Beach and a new Lexus (while they might appreciate and get those material things, that is not their primary motivation).

Admittedly, I've struggled with how I feel about this with each new agile company I see or coach I meet. I ask myself, "Were they passionate about agile before this recent boom?", but I've also had to ask myself if that matters. Would it be okay, with me, if they weren't passionate about agile and were only in it for the money? What if they were good at coaching, training or in other ways helping companies and people? What if they become passionate about it? Those questions, and more, are ones I can't answer and, I've found, that I cannot decide the worthiness of others being in this field. I can only look at myself in the mirror and refine what's there.

To this end, I put together a list to help me determine my guiding values and, as the Agile Manifesto does, did so in a comparative manner. May it be of some help to you.

Purpose-Motivated over Money-Driven
Extending the Vision over Keeping to the Familiar
Stretching Myself over Staying Comfortable
Helping the Whole over Benefiting a Few
Abundance Mentality over Scarcity Mindset
Others' Needs over Self-Interest
Giving Back over Accumulating
Making a Difference over Busyness
Significance over Success

That is, while it may be fine for others to value the items on the right, I value the items on the left more.

Goals for Agile Teams

When working with companies who are trying to adopt, or correct, an agile approach to their projects or product development, usually using Scrum, the situation, needs and specific problems vary. But the core needs, and root cause of problems, doesn't typically vary that much.

With that in mind, I have a few goals that help me stay focused on the "main and the plain" of agile, and begin with the end in mind (to borrow from Steven Covey).

My Goals for New Agile Teams :

1. That they know, understand and practice the Scrum framework
2. That they are aware of where they aren't, the possible consequences, and the limitations (domain) of Scrum
3. That they know, understand, and are living the agile principles, Scrum values and self-organization
4. That they are aware of other agile methods and the pros and cons
5. That they are connected to community and learning sources
6. That they gel and are moving forward as a team
7. To understand why management wants Scrum/agile here
8. To know their definition of success
9. To understand what they see as their opportunities and challenges

And my personal goals when coaching agile teams:

1. That I set and meet expectations each week
2. That goals are stated and progress visible
3. That goals clearly align with my customer's goals
4. That I understand what it means to meet and exceed expectations
5. That I understand what will help them move forward, and have contributed to that

Technorati Tags: agile, scrum, project-management, coaching, eds-pick, business

Kanban Book Review

I just finished reading Kanban and Scrum - making the most of both, by Henrik Kniberg and Mattias Skarin. You can download it for free. I was very impressed by this self-published book, enough so to place an order today on Lulu for a paperback version.

Despite my readings of blogs and listening to podcasts on Kanban, it still wasn't clear to me. Knibert and Skarin broke it down so clearly for me that I finally got it. They took a simple approach, used lots of drawings, as well as comparisons to Scrum that helped related it to something I did know.

Here are some of my favorite quotes from the book:

As teams evolved from individuals to self organizing units, the managers realized they were facing a new set of leadership challenges. They needed to deal more with people issues – handling complaints, defining shared goals, resolving conflicts, and negotiating agreements.
...
The WIP limits are there to stop problems from getting out of hand, so if things are flowing smoothly the WIP limits aren’t really used.
...
The only thing that Kanban prescribes is that the work flow should be visual, and that WIP should be limited.
...
What should the Kanban limits be?
When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. If there is no bottleneck that is an indication that the Kanban limit might be too low, since the reason for having the limit was to reduce the risk of feeding bottlenecks downstream.
...
If you notice that many items sit still for a long time without being worked on, that is an indication that the Kanban limit might be too high.
•    Too low kanban limit => idle people => bad productivity
•    Too high kanban limit => idle tasks => bad lead time

...value stream map. It’s basically a visualization of the value chain and provides insight into work states, flow and time through the system (cycle time).

Over time, managers learned that if they kept number of concurrent projects low, they didn’t keep stakeholders waiting.
The need to project delivery date was no longer a big issue. These lead managers to stop asking for up front estimates. They only did if they feared they would keep people waiting.

And I particularly loved this approach with management, and of course their results overall:

But keeping traction on complex, infrastructure type issues was a harder ordeal. To deal with that we introduced the ability for teams to assign up to 2 “team impediments” to their managers.
The rules where:
1. Manager can work on two slots at any single point of time.
2.    If both are full, you can add a new one as long as you remove the less important one.
3. Team decides when issue is solved.

Three months after introducing Kanban, the system administration team was awarded “best performing team” in the IT department by the management. At the same time, the system administration team was also voted as one of top three “positive experiences” in the company retrospective. The company retrospective is a company-wide event that happens every 6 weeks, and this was the first time that a team turned up on the top 3 list! And just 3 months earlier these teams had been bottlenecks that most people were complaining about.

For those trying to learn about Kanban, or those responsible for leading, coaching and/or training Scrum in your company or for clients, I highly recommended this book.

Technorati Tags: agile, kanban, lean, scrum

Agile Adoption

Several good posts related to agile adoption -

First, from the Orange County APLN meeting in February:
"One recommendation was to use coaches and train all team members, as noted in a post on Yahoo's Scrum adoption. See Lessons from Yahoo Scrum Adoption for more.

Also, some talked about on large, complex projects, that getting good, thin slices of end-to-end feature/functionality is crtical, and difficult. See Elephant Carpaccio and Walking Skeleton.
...
Others also described, and warned those looking to adopt Scrum, of the problems with ScrumBut.

Also, for environments of continuous changes, such as product support or operations, Kanban might be a good approach.

A question, and spirited debate, occurred around what is pair programming, what is the value and how do you sell it to management?

We also discussed the improvement (60–90% drop in defect density for some teams) from using Test Driven Development (TDD) documented in a Microsoft paper."

The discussion at the APLN meeting got me thinking, along the lines of XP dev practices such as TDD and pair programming, oftwo articles I keep telling others to read are the Decline and Fall of Agile and another on Flaccid Scrum.

For at-a-glance view, check out two versions of why agile adoptions fail, with 12 Agile Adoption Failure Modes and 11 Ways Agile Adoptions Fail.

Other articles or posts you would recommend?

Technorati Tags: agile, scrum, project management, scrummaster, project manager

Agile Leadership and Management Presentations

From my two Code Camp presentations on agile, leadership, management and strengths, I've linked the handouts and made a list of the books referenced. Great conversation and shared learning with everyone. Several additional resources that I mentioned are Pragmatic Learning and Thinking, Mavericks at Work and What Got You Here Won't Get You There. I added those books to a list of leadership and management books on Amazon to make it easier to track.

Here are the links to my presentations on Leading a Team and Developing Team Members - management and leadership and Scrum and Agile - People and Problems: Teambuilding with Agile and Strengths.

Technorati Tags: agile, scrum, management, teams, projects

Salesforce.com's Success with Agile

Perhaps the best slideshow I have seen on agile implementation\agile adoption in the enterprise.

• How do you roll-out Scrum?
• How do teams learn Scrum?
• Are there metrics or proof that agile works?
• How do you get executives to buy-in?
• What about the problems with Scrum or some saying that Scrum is failing?
• What is the role of agile coaches?
• How many product managers should go to product owner training?
• What does successful agile adoption look like?

From the Scrum Gathering conference of 2008 in Chicago, presented by Salesforce.com, titled "A Year of Living Dangerously".

The Year of Living Dangerously: Extraordinary Results for an Enterprise Agile Revolution

View more presentations from Steve Greene.

Technorati Tags: agile, scrum, management, saas, web2.0

Offshore Agile Teams

Good webcast on offshore development teams using agile (perhaps Scrum). The image below shows the medicine that must be taken - colocated teams. Although it sounds like a tough sell, companies that have done this report not only good results but positive experiences from team members.

The notes in red are mine, pointing out the fact that most offshore teams that I have worked with or know people involved with are operating in a dysfunctional structure.

Technorati Tags: agile, offshore, Scrum, software development

Example of Team Agreements List

Team agreements recently came up at a conference. I picked them up from another coach as a means to help set-up a baseline of expectations that the team can have of each other. They don't take much time to set-up (almost fun) but pay dividends back to the team throughout the project. We start each Scrum Master certification training with a working agreement of what makes a great class.

[2/27/17] I updated the list with some new items that pertain more to technical practices (per XP, DevOps and covered in the Certified Scrum Developer workshop).

Here's an example of a Team Agreements list:

1.    Tell the truth and be transparent
2.    Treat all team members with respect and value other team member’s time.
3.    Value team members’ thoughts
4.    When in the team room, cell phones on low tone and take calls outside of the room. During meetings, cell phones set to silent.
5.    Formal meetings have an agenda, have focused participation and begin/end on time (unless all agree to change it).
6.    Have one conversation at a time including during phone conferences.
7.    ScrumMaster will maintain a calendar in an Excel spreadsheet that will include planned leave and holidays. This will be reviewed and confirmed at start of sprint planning.
8.    Be present during specified co-location days from Monday through Friday, 1:30 pm to 10:30 pm, except for travel. Remote team members can work 9:30 AM – 5:30 PM on Fridays.
9.    Be available by cell phone when needed.
10.    Daily stand-up meeting 2:15 - 2:30 PM
11.    Daily Scrum of Scrums call with US from 9:45 – 10:00 PM (9:15 PST)
12.    Task estimated hours to completion to be updated in Rally/VersionOne/JIRA/TFS daily by 6 PM
13.    Dinner hour is free time
14.    All new code (or code touched) must have unit tests.
15.    At least one story per sprint must have the acceptance tests automated.
16.    One team member must learn something new (take a story they don't know) per sprint.
17.    Limit the number of stories in progress to the number of team members (keeps QA from getting overloaded). Often referred to as a WIP limit.
18.    We must have a team name. And the team name changes if management changes the team.
19.    Developers must check-in their code [every 2 hours, or 4 hours, or daily].
20.    If a developer broke the build, they must undue their change if they can't fix it within 10 minutes.
21.    We must pair on at least one story per sprint. A similar agreement is "We must have at least one mob programming session per sprint."
22.   Leave the code cleaner than you found it (relentless refactoring).
23.   At least [x] items from the retrospective must be worked on the next sprint (typically between 1 - 3).
24.   At Daily Scrum, only the person with the talking stick/ball/rat can talk.
25.   If anyone is late to the Daily Scrum they: put a dollar in the beer/cake/donuts jars, or have to sing and be recorded and uploaded to YouTube (true), tell a joke. Or, one team reversed it - if everyone was on time, the team got cake/pizza/new car. :-)
26.    HAVE LOTS AND LOTS OF FUN!
Technorati Tags: agile, scrum, communication, management, teams, projects

Sample Agenda for a Sprint Planning Meeting

Here's a thorough, high-level agenda for a Sprint Planning meeting. Of course, don't use what you don't need...

1. Product Vision and Roadmap [Product Owner]
2. Development status, state of our architecture, results of previous iterations [Team members]
3. Iteration name and theme [ScrumMaster]
4. Velocity in previous iteration(s) [ScrumMaster]
5. Iteration timebox (dates, working days) [ScrumMaster]
6. Team capacity (availability) [Team members]
7. Issues and concerns? [ScrumMaster]
8. Review and update definition of Done [Team members]
9. Stories/items from the backlog to consider [Product Owner]
10. Tasking out [Agile Team]
11. Issues, Dependencies and Assumptions [ScrumMaster]
12 Commit! [Agile Team]Technorati Tags: agile, scrum, sprint, project management, scrummaster, project manager

Iteration vs Release Planning

Saw this simple sprint iteration and releases comparison chart in a Rally training page. I like the line on the difference of focus - release is "what" and iteration is "how." Just keeping that in mind will help guide sprint planning meetings much better. Also, given that the focus of sprint planning is task-estimating, not story-writing, the assumption is that the top of the product backlog (sprint backlog) is well groomed. Taken from Rally's Agile Planning Step-by-Step Guides.

Technorati Tags: agile, scrum, project management

Should ScrumMasters Code?

One of my mentor's believed that ScrumMasters should be programming as part of their general duties. If you're in IT, it's likely you know some piece of the programming being done, and if not, have the ability to learn some small aspect (SQL, scripting, batch files, etc).

As I finish up my first Rails project several months ago, I learned a number of things. In the end, I switched my laptop over to a dual-boot Windows\Ubuntu machine. I'm been using Ubuntu ever since, and only had to use Windows for old specialty apps (and even those now have web-based versions). I'm emailing, exchanging and editing documents, tracking bugs, organizing and prioritizing work all from Ubuntu. The boot time is faster, installing apps is easier, and viewing all my windows greater in Ubuntu.

I went to Ubuntu in order to get the developer's web site up and running on my machine. Along the way, I've learned about Subversion and Git, production vs. dev mode on Rails, and how configurations are saved and published (or held).

On my current project, I've started using soapUI to help do some testing for the QA team members. By reading a few pages of the documentation, I learned how to automate the tests and use XPath to confirm data items in the responses. Just getting that hands-on to know the versions of our WSDLs, the endpoint changes, seeing data and changes in the payload gave me a deeper and stronger understanding of the work (and challenges) of what the team is trying to accomplish.

I have a renewed belief that the agile project manager is much more effective when their hands are in the code at least some small percent of the time.

If you're a ScrumMaster, are you doing any programming? Would it help? If so, how? If no, why not? If you're not a ScrumMaster, but a team member, how would you feel about your ScrumMaster getting involved in this way? What if it meant asking more questions, learning and perhaps even making some mistakes?

Technorati Tags: scrum, project management, agile, scrummaster, programming

Kanban and Scrum, Black Box and White Box

This post is a good description of Scrum vs. Kanban - Scrum is a black box (and I'd add "a closed black box", isolated from the Enterprise, but that's part of why it works) and Kanban is a white box. It seems part of the success of Scrum is it's simplicity - you can cover the process, roles and artifacts in 10 minutes. But my experience is that it works best out of the box in small, flat, focused, and/or aggressive companies and needs adjustments for other environments (not thrown away, just adjusting). I've seen some throw it away because Scrum didn't work immediately and easily. Scrum is not a panacea, but commitment and tailoring when needed (e.g., combined with Kanban) will still bring success.

Technorati Tags: agile, scrum, kanban
Trackback: http://www.typepad.com/services/trackback/6a00d83452ee9169e2011571fcf307970b

Improving Retrospectives

For years I've done the classic retrospective at the end of each sprint, asking the team "What worked? What didn't work?" or "More of? Less of? Start? Stop?" But I tried some new techniques recently, and the response was much better.
Most importantly, I used several ideas listed and described in Agile Retrospectives. To start, I asked the team members to choose one of four categories to represent how they felt about being there. This helped to focus and confirm what they hoped to get out of the meeting. I then clarified our values, updating our team agreement with this key, guiding information. The last thing I did was have each of the team members write down 5 idea for improving our scrum. After collecting their papers, I wrote them down on the wall and had the team come up and cast four votes per team member (we had about 20+ ideas).
Throughout the rest of the week of sprint planning, their clarified values and top ideas/problem solutions were referred to again and again, and really helped to shape and guide how the user stories and acceptance criteria were crafted, as well as how the tasks were broken out.
You can also use the "What worked/didn't work" at the end of any recurring meeting in order to improve it the next time.
I highly recommend Larsen's book. The return on investment for improving your retrospectives is significant.

Looking Outside for Ideas

As much as people want to "think outside the box", it really is very difficult to think of an idea or a viewpoint that you wouldn't naturally think of.

As recent Wall Street Journal article describes how Campbell Soup is looking outside for ideas (MarketingProf's summary here). This same approach that a gold mining company took is described in detail, including the great results, in Mavericks at Work.

If this is a good, successful idea, how are you doing it? Scenarios could include asking a Scrum Coach to review your work (your product backlog, sprint backlogs, user stories), setting aside time regularly to read on the topics you're involved in at work (Scrum, QA, automation, tools, the business sector you are in), and setting up periodic meeting-of-the-minds, whether trusted colleagues, a conference or seminar.

I have not once regretted the time I have set aside for any of these. There are always new ideas that I never would have considered that were immediately application to situations and challenges that I was facing. Yet I still don't make it the priority that reflects the value it is.

How about you - where do your ideas come from? How do make sure you put things in place that help you at what you do?

Story Card Template

As I was setting up another new project in a tool I use, I reviewed the default template used for the story cards. Although I always only use parts of it depending on the project, I think it's good to review all of it each time to consider what the needs of the new project are, rather then be unthinking somewhat and stick with "what works" in a general sense. The template follows:

Story Card Description

The 2-3 sentence version of what the card is about

Business Context

Why is this valuable to the business? What is the goal?

Scope Exclusions

Call out anything that is explicitly not included in the card that could be inferred.

Prerequisites to Card Development

* Other story cards that need to be played first
* Data requirements

Detailed Story Narrative

Step by step description of the happy path scenario. Can be numbered or bulleted. Alternate flows can be captured in the acceptance criteria.

Validations

Include any special business rules or validations here.

Authorization

Include special security requirements here.

UI

Indicate what views are impacted by the card. If possible, include a reference to a low-fi prototype.

Additional Notes for Developer

Include any additional notes that you would like to include here to help the developer understand the context of the card.

Open Issues

Include any questions or open issues that we don’t know the answer to when writing the initial draft of the card. Often phrasing the issue as a question and following it up with the solution clearly labeled as the ‘Answer’ helps with readability.

Sample:

Should there be any restrictions based upon the party being a minor, a fatality or having legal representation?

Answer: No. At this point in time, the business has asked for this as a convenience feature that will always bring them directly to edit mode. Even when these scenarios occur today, the Contact Tab is filled out and the Contact Notes will indicate details about the contact (i.e. spoke with the parents of this party or the next of kin).

Acceptance Criteria

Things that the BA will verify during card signoff. Will be used as the starting point from which QA will expand when creating their test cases.

Scenario 1: Description of Scenario

1. Step 1 to demonstrate the criteria
   
2. Step 2 to demonstrate the criteria
   
3. Step 3 to demonstrate the criteria …
   

Problems with Mingle Project Management

I like Mingle, but it's not perfect. I've posted a few times about the benefits of using Mingle, so now I'll mention the problems.

We had read of performance issues, but I experienced where the cliff is. We have Mingle running on a virtual server with 4 GB of memory. We created a custom project using one tree and approximately 15 fields in the card. As we approached 1200-1500 cards in the project, performance dropped significantly. Users could count to 10 - 30 before items loaded, especially in grid view. As we neared 2000, grid view failed completely. Users new to Mingle started asking for another tool. Stakeholders in planning meetings would lose their patience waiting on it. My advice is find a way to keep bugs and features separate. Delete old, fixed bugs, and be disciplined to keep the features list (product backlog) short. Why keep low priority items when there are months of highs in the list?

Exporting data is a pain. Cut and paste text into Excel gets you by, but you can't use any filters (WHERE clause) nor choose what fields to include or exclude. You get it all. Massaging it into something useful for management can become hours per week if you have large backlogs.

As far as I can tell, you can't enforce data integrity. I tried without success. And garbage in\garbage out feeds the two items above that can become a monster.

The project templates look wonderful (XP, Scrum, Agile Hybrid), but there's only one thin page of documentation on their site for each one on what comprises each template. Trying to figure out how to use them (what the workflow is, the objects, details) is essentially up to you. Don't get me wrong - I really appreciate these views into how Thoughtworks does agile project management, but as I kept poking around, feeling like I was trying to put together the lifestyle of some ancient race based on artifacts, I kept thinking, "The creator of this template could have taken one day to document it and the whole world would be ready to go." As is, the whole world will play Sherlock Holmes and my guess is many will give up and go to what they know and lose out on a great agile mind-share opportunity.

agile, scrum, xp, extreme programming, project management, mingle

Agile Planning Poker Rules

I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it.

One item that came up in a recent sprint retrospectives (in the "Where do We Need to Improve?" list) was getting better requirements and estimates. So, after the following planning meeting, where the CEO selected his highest priority items, the team met to review those items.

The meeting seemed to be another poor meeting of nothing definite or different being done - lot's of "Well, I'll need to look at that one more," or "Well, management says it needs to be done by next week, so what does it matter how long I think it will take?". I was ready to call the meeting until Martin asked about the planning poker cards (shwag from Phil Scott at the Agile Panel Discussion at the LA Code Camp). He hadn't used them before so we walked through the instructions:

1. Each team member is given a set of cards.
2. One person read the item to be estimated.
3. The team & customer discuss the item.
4. Each team member privately selects a card representing his/her relative estimate.
5. After all have chosen a card, everyone shows the chosen card.
6. If all estimates match, that item's estimate is complete.
7. If estimates are not the same, the group discusses the differences (focusing on the outlying values).
8. Repeat until consensus is reached.

Few notes on modifications we made to the rules -

• We don't have any business members there, but call in the requester if needed.
• We re-estimate until within one card value of each other, or take the median value if there's a majority.

The team really enjoyed, and benefited from the experience. The secrecy of each persons' pick not only made it fun for them, but it got each person so plugged into the task at hand. There was kidding of those who's estimates were way outside the norm. For outrageously low estimates, we rewarded the low-bidder's confidence by giving them that task, but with an agreement that if they met the estimate, we'd buy them lunch. It was particularly enjoyable to see how much this engaged Jeoff, our only team member with the strength Competition. There was great discussion on all the tasks the team had ahead of them, and we left the meeting with a lot more shared knowledge, both where we're weak and where we're strong.

You can buy planning poker card sets from Mike Cohn's Mountain Goat Software site.Technorati Tags: agile, scrum, project managment, software, team building

Agile Leadership Coaching Quotes

I was at a leadership coaching event and had these quotes as good takeaways. Although the training wasn't specific to agile environments, I think they all apply quite well.

• It's a leader's job to make the goals clear, and the team's to make it work. 
  
• In a dynamic environment, it's more important to have strategic positioning than strategic planning. 
  
• The fix for bad leadership isn't teams or teamwork, it's good leadership. 
  
• You don't know what you're capable of. 
  
• There's often a gap between information and application. 
  
• What are your growth hashmarks? Because speed acclimates and it will be hard to tell if you are growing as a leader or not.
  
• The ideal situation is the right job [or role] + the right mindset.
  

Agile Project Management Tools - Mingle, Rally, or...?

I previously posted on comparing different agile project management tools: Mingle, ScrumWorks and an Excel file with dates, hours and a burn down chart. After hearing several agile consultants at Code Camp, I thought I should pass on their (better?) response. 

The question on a tool recommendation came from an audience member who said they had been using Rally, and end the end required one person full time just to manage the tool and data. KenKolcheir, who works for ThoughtWorks, obviously recommended Mingle, with a laugh, but I heartily agree it is a great, easy to use tool. Denise Phillips recommended VersionOne.

But the consensus from all the panelists was to keep it as simple as you can. If you can get by with cards on Post-Its stuck to a wall, do it. Also, this method provides a ready "information radiator" that helps visibility, communication and focus for those nearby or come and go interacting with the team. If you choose to use a the tools from ThoughtWorks, Rally, VersionOne, or Microsoft's Team System 2008, it would be very helpful to have a large monitor or fatscreen on the wall with your cards or a dashboard (with burndown, etc) as the information radiator.

I tried Post-Its, but switched to Mingle so our CEO could access the product and sprint backlogs from his computer and be more directly involved. This is what we needed and has been a key to the success of the organization really getting behind scrum.

USC SoCal Code Camp Presentation Docs

Below are the handouts used for the presentations at the SoCal Code Camp at USC. 

Session 1 - Leading a Team and Developing Team Members - Currently or hopefully leading a small team, managing a project, or over a department? We reviewed the research from several top management experts including Jim Collin's Good to Great, Marcus Buckingham's First Break All the Rules, and Ken Blanchard's One Minute Manager. Using agile as our team context, we reviewed leadership, management, the difference, and what is the role of management today when agile teams are self-managing - the Agile Manager and organizational change. The handout is here. 

Session 2 - Agile Scrum Method with Strength-Based Teams - This session was an overview of the Scrum agile process, tools I've used such as cards and Mingle, and highlights a strengths-based approach which takes advantage of using team members for tasks and roles where they are more likely to excel. Scrum is simple (but not easy) and a tremendous help to achieving success in projects. Agile environments are designed to capitalize on each individual's unique strengths, but there's not much guidance out there on how to do this. This workshop reviewed the different approaches and levels I've used with a strengths-based approach on my Scrum teams. The handout is here.

Session 3 - Discovering Your Strengths - What are you naturally best at? How can you leverage that to become world class? It might be innovation, bringing out the best in others, or knocking out task after task. Many of us don't know our strengths, much less how to build our work day and careers around these natural talents. Instead, guided by our managers and others, we become experts in our weaknesses and spend our lives trying to address these "areas for improvement", while our strengths lie dormant. We review some of the book StrengthsFinder 2.0 and watched the first of six videos from Marcus Buckingham's strengths video series. We covered how to leverage your strengths and how to continue to develop them. The handout is coming...

Session 4 - Agile Panel Discussion with Phil Scott - Neudesic, Denise Phillips, Paul Hodgetts - AgileLogic  and Ken Kolchier - ThoughtWorks. No notes yet but I will try to collect the questions and answers. 

Code Camp Connections

If you are coming to the SoCal Code Camp, you can stay connected to others through the SoCal Code Camp group on LinkedIn. Click here to join and connect with others who are a part of it. Also, you get get real time updates and join the code camp conversation on Twitter. Click here and then click Follow.

Agile and New Ideas for the Enterprise

In a previous post, I commented on what to do after successful implementation of agile to an IT team. What I found from others was that the next step is to move towards the agile enterprise, and I pointed to looking at the P & L and what drives ROI. A complement to this "what" is "how", and a great book on how to introduce this agile growth, and other new ideas, is Fearless Change by Mary Lynn Manns and Linda Rising. It is a book of very practical and comprehensive patterns to use to get support and buy-in, and it is the sum of collected experiences from many professionals.

Despite my best efforts, I often see problems and opportunities through my lens and not through the lens of those I work with. The book references work by E.M. Rogers which breaks down people into groups of Innovators, Early Adopters, Early Majority, Late Majority and Laggards. While I and others in IT, web 2.0, or project management might be Innovators or Early Adopters, two thirds of the world around us are Early Majority or Late Majority. These groups need to see others successful with an idea first, or are naturally cautious or skeptical (they could have the theme Deliberative). Moving a new idea such as Agile Enterprise, with all the visibility and accountability, is a paradigm shift, foreign and likely scary for some of the very people that will not only benefit most from it, but also whom you vitally need their support. From my initial reading of Fearless Change, I believe this book will be a significant help in getting you there. Also, understanding the strengths of these stakeholders will help you speak their language and motivate them.

Book Review - Agile Software Development w Scrum

ASDS is a very good book, but only for the few who want to be Scrum experts. The material is thorough, and not necessarily easy to get through, in part because the Schwaber and Beedle walk through every part of Scrum in detail, as well as cover situations that likely don't apply to most, and they even go through philosophical views that some may care little about.

To be sure, there are gems in the book, and I learned a few important points, but I have been to ScrumMaster certification training, read two other agile books, and been mentored by a CSM/PMP. I feel the book only moved me from 80% comfort level with Scrum to 85%.

If you are a consultant managing projects, or you want to teach, coach or train in this area, read the book. If you a internal project manager,product manager, or IT manager, I recommend you get Agile and Iterative Development: A Manager's Guide and read the section on Scrum. It's simpler, cleaner, and the rest of the book gives good background to agile and options you may want to consider.

If you are a team or development lead, or the senior developer, get Agile Project Management with Scrum. It's an even easier read, focused solely on Scrum and gives lots of enjoyable stories of real situations the author went through, good and bad.

After Scrum, the Agile Enterprise

The other day, Joseph Little (blog here) posted to the Scrum Development board on Yahoo! asking for input on what to include in an advanced course that he and Jeff Sutherland were leading (Agile 201). One item I raised was "What do you do when your agile project efforts are going well? What's the next step to capitalize on successful to move agile into the enterprise?"

Well, I came across a great post on exactly that - Agile Leaders - The Next Hurdle from Steve Garnett. Simply put, the next step is Lean Thinking & Financial Understanding

"It's alright being bloody great at Agile, and knowing how to deliver software and create self-organizing teams, but always remember that the engine for change, the real way to effect change, is control of the P&L."

Agile2008 Conference Submission

Agile2008 released the conference track recently here.One presentation that won't be there is my submission. Though it had some positive feedback, it didn't make the cut.

As the presentation was unique among the others I reviewed, I thought I would post it for others. I submitted it under the Leadership and Teams track. Despite the let down that I wasn't selected, I had a career highlight in getting very positive feedback from Jim Highsmith. :-)


Agile Strengths-Based Teams - How to Coach and Lead According to Strengths

This workshop will review the different approaches and levels I’ve used with a strengths-based approach on my Scrum teams. We will discuss my experiences at the individual level, listing team members’ specific strengths (with descriptions) and how I created new team roles tailored to allow each member to play to their strengths, involving the team in the way they work, and fostering improved communication and interdependency. Also, group discussion could cover hypothetical roles and situations, or run through a simplified strengths assessment for attendess and then walk through how they could make adjustments to leverage those strengths more on their team and with stakeholders and customers.

How Does Strengths Relate to Agile?
Jim Highsmith writes, “Agile Software Development Ecosystems are designed to capitalize on each individual’s and each team’s unique strengths.” and also that “developing each individual’s capabilities” is a key contribution to project success. In the spirit of agile, working with others according to their strengths is part of valuing individuals and interactions over processes and tools. And adding the strengths paradigm to agile project management addresses several key points from the Agile Project Leaders Network Wiki of Knowledge, such as:

• Individual Leadership Style - Involving the team in determining the way they work
• Handling Team Dynamics - Encouraging individuals to self select tasks
• How to generate an open environment where people feel safe to express themselves.

Aren’t We Already Doing This?
Agile leaders should use a strengths-based approach as a tool, but don’t often do. Most people don’t know how to identify their strengths at a granularity that is practical and helpful. Those that do most likely don’t know how to make changes in how they work that enables them to capitalize on those strengths.

Strengths Is Not a Silver Bullet, But an Agile Accelerator Tool
In terms of in terms of productivity, profitability and employee retention, managers using a strengths approach had a 86% greater success rate than other managers. Strengths-based teams performed 44% better. But the most powerful benefit of the strengths movement is when agile leaders use it.

NOTE: Depending on group consensus, have a separate short session or workshop where the group takes Gallup's StrengthsFinder assessment. The results could be discussed, and attendees could then come to this workshop knowing their strenths profile.

Process/Mechanics
Facilitated a discussion on my experiences of introducing a strengths-based approach within a Scrum team at the individual level, listing team members’ specific strengths (with descriptions) and creation of new team roles tailored to allow each member to play to their strengths.

I. Samples of My Agile Strengths Implementation Experience

1. Team Member A has Strengths of ‘Focus’, ‘Deliberative’ and ‘Competitive’
2. Team Member B Goes From Impractical Complainer to Responsible, Driving Junior ScrumMaster
3. Team Finally Understands Team Member C, Because of Her Strengths

II. Review how to leverage strengths for better performance from ourselves and our teams. We would discuss:

1. Strengths themes vs. granular strengths
2. How to grow your strengths week by week
3. Ways to leverage the power of the agile + strengths combination
4. What if there is lots of overlap or gaps?

Finally, discuss how my efforts and experience coaching and influencing the organization in both agile and strengths, and the parallels of improved communication and collaboration.

Leadership is Simple, But Not Easy

As posted on the Mavericks at Work blog, leadership is simple but not easy. Same with agile. In the end, all you can continually do without being fueled by results is to be the change you want to be.

What makes Southwest Airlines successful has been studied, written about and public knowledge for years, as mentioned in the Mavericks blog here and here. But companies still don't (or can't) do what Southwest does.

The success of agile has been studied, written about and public knowledge for years, but companies, and even teams, still don't (or culturally can't) do it. The barriers I've seen are mainly letting go of control and trusting others.

Agile Worldview Quotes - Scattering Seeds

I just read in Mike Beedle and Ken Schwaber's Agile Software Development with Scrum that "Scrum represents a competing worldview when compared to the many other styles of software development or business organization." I've never heard the term "worldview" associated with anything in software development, but I fully agree.

Agile isn't just about how a team of developers builds something, it's reaches into the business - how the team works with the other departments, how the business must have a single voice and must prioritize requests.

Something I've found useful is to include in all of my email random quotes I've saved which reflect this worldview. The program I use is Qliner Quotes, and its free.

Here is a sample of some of the quotes:

I'm going to make mistakes, but I've got to be able to look myself in the mirror and say to myself that I believed in that decision and mistakes are okay. And once I make those mistakes I can adapt and change. - Frank Addante interview on Venture Voice

Companies with the most values based critiques of their industries often turn out to be the savviest and most aggressive competitors. - Taylor and LaBarre, Mavericks at Work

Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.  - Bob Sutton, Professor of Management Science at Stanford University

Core values are not something people "buy in" to. Executives often ask me, "How do we get people to share our core values?" You don't. Instead, the task is to find people who are already predisposed to sharing your core values. You must attract and then retain these people and let those who aren't predisposed to sharing your core values go elsewhere. - Jim Collins, Good to Great

Courage in Scrum isn't a visible, tangible thing. It is not some kind or romantic heroism. Instead, it is having the guts, the determination, to do the best you can. It's the stubbornness not to give up, but to figure out how to meet commitments. This type of courage is gritty, not glorious. - Mike Beedle, Agile Software Development with Scrum

Harmony itself is good, I suppose, if it comes as a result of working through issues constantly and cycling through conflict. But if it comes only as a result of people holding back their opinions and honest concerns, then it's a bad thing.  - Patrick Lencioni, Five Dysfunctions of a Team

When I'm building a team, I look for people who love to win. If I can't find those, I look for people who hate to lose. I want people around me who have passion. - Mark Beeson

A good plan violently executed now is better than a perfect plan executed next week. - General George S. Patton

Excellent firms don't believe in excellence, only in constant improvement and constant change. - Tom Peters

A manager must be able to do four activities extremely well: select a person, set expectations, motivate the person, develop the person. The manager role is the catalyst role. - Marcus Buckingham and Curt W. Coffman, First Break All the Rules

In the world according to great managers, the employee is the star.  The manager is the agent.  And, as in the world of performing arts, the agent expects a great deal from his stars. - Marcus Buckingham and Curt W. Coffman, First Break All the Rules

Are you going to take the risk to be different? Because no one is drawn to ordinary or average. And if you're willing to be different, be warned. Leaders are always controversial. Followers fit in. - T.D. Jakes

To succeed, a project relies on information from very different people: on one side are customers; on the other side is the technical team. If either side dominates these communications, the project loses. - Mike Cohn

A key role servant leaders often play is facilitating necessary changes. As a result, it's imperative that these leaders recognize there are four levels of change that vary in degrees of difficulty and time: knowledge, attitudes, behaviors and organizational change. The last one is the most difficult, because now you're attempting to influence the knowledge, attitudes and behaviors of multiple people. - Ken Blanchard

"The record for successful software projects is dismal indeed, but there's a new kid on the block: agile programming. Agile principles include flexibility, teamwork, trust, and reflection. But sadly, these environments are few and far between." - CIO.com

Changes in Online Advertising

I was training a new project team member on how the advertising works on my company's website, all as part of a project to migrate the site to a new content management system. He wasn't aware of the business behind the banner ads that our users see when the visit our site.

Just this year, Google bought DoubleClick for $3.1 billion. Microsoft bought aQuantive for $6 billion. AOL buys Quigo for $340 million. Why such big purchases? In part because internet advertising is expected to top $27 billion this year, and there are a lot of people and companies who would like to make advertising money from all the advertisers. But picture the stock market and other financial markets. I might want to invest some savings I have, but I wouldn't do it myself. The most cost-efficient (and time-efficient) is to work with a broker who will make the transaction. Ad networks act the same as the broker - taking the money to be invested by the advertiser and spending where it will have returns most likely to make the advertiser happy.

In my broker analogy, I might want my money to go into options, or environmentally friendly companies only. The broker would then be limited to some markets (Chicago Board of Options Exchange) or need to know companies in several markets that represent a given sector. In the same way, some ad networks only provide a certain format of advertising (video on VideoEgg, or text links through Google's AdSense), while some ad networks specialize on demographic (Hispanic sites and visitors through HispanoClick).

In my experience with DoubleClick's DART for Publishers, we focus on where we want ads to be displayed on our site. You can add ad networks (which provides the ads themselves) through DART, as well as schedule and manage the ad campaigns.

To implement online ads, we first define how many ads will be on a given page, and what dimensions the ads will be. We give each of these ad slots an ID, and then place the same number of code\tags, each with its own ID, into our webpage (see the nice overview on Google's Ad Manager here). Now when we load our webpage, the tags call out to the ad server, which returns an ad. The ad server also tracks which ads where server where and when, and which were clicked.

Part of the business opportunity is that these ad networks take a cut of the money coming from the source (advertiser) to the destination (publisher site where ad displayed). Part of the business problem is that publisher want the best paying ads, but aren't in control of which ads come trough and their pay rate. Ideally, publishers would cut out the middle man, but managing and serving ads is challenging, while calling all the advertisers and lining up the deals is time consuming.

If we want to try and manage the ad serving with a tool, there are free ad management solutions (Google's Ad Manager for one). There are also now meta ad servers that sit between the publisher and the ad network. These applications work with many ad networks, while gathering statistics on ad performance and even making recommendations (see The Rubicon Project for an example).

Comparing Mingle and ScrumWorks Agile Scrum Project Management Software

Thanks to a recommendation, I'm now using Mingle. I've found it easier to use than ScrumWorks and Excel for managing the product backlog, sprints, user stories, and tasks. My favorite feature is the ability to group stories and tasks by sprint, each card color coded to reflect status, and you can drag the cards into other sprints.

One draw back is that it's hard to beat the visibility and energy of Post-It cards on the wall in status swimlanes, but you also can't export the Post-Its into an Excel sheet to send to management for a quick status report.

Each project management tool I've tried has it's drawbacks.

1. The Excel worksheet with stories, tasks and burndown was labor intensive to set-up or change very much, and often confused newcomers to the team.
2. ScrumWorks is not intuitive, and couldn't show burndown on partially complete stories and tasks.
3. The Post-Its can't be mass-updated, reported on, nor accessed remotely.
4. Mingle doesn't have a burn-down (that I found, although rel 1.1 is said to have one), and performance is pretty bad.

Right now, the customer likes to see the project overview, and Mingle provides that at-a-glance better than the others, so I'll be sticking with Mingle for now.

Office Developer Conference - ODC 2008

Some notes from the Microsoft Office Developer Conference (ODC 2008) in San Jose -

I was most impressed with InfoPath 2007. It allows for simple creation of forms for data entry or lookup without code, while allowing access to workflow and .net object model for coding if required. I also read how designers and developers are using it for prototyping user experience (UX) on new sites, applications and features. This sounds good, given that you can build a page in a couple minutes that accesses and displays real data.

InfoPath and SharePoint, and any custom programming, can use Windows Workflow to automate emails, task or list creation, and follow-up actions. The assignee of an IT Ticket can have a task created and assigned to them, as well as sent follow-up emails including escalation until the ticket is completed. Also, you can publish InfoPath forms to SharePoint to be accessed as webpages. No need for InfoPath on every desktop.

Visual Studio 2008 is geared to leverage SharePoint for .Net developers, both with access to workflow, workflow templates, tools to simplify building and deploying new features. SharePoint Service Pack 1.1 just came out, and it’s loaded – almost a Service Pack 2.0 release.

A new XML standard allows sharing data across the Office applications, and allows customization of the ribbon in those apps. Microsoft recommends keeping office workers in the applications they are familiar with, rather than go to other, separate apps to do parts of their job. Examples include the AdSage add-in, and the Xobni Outlook plug-in (http://www.xobni.com/learnmore/). Lot's of talk of the user experience as "contextual" or "immersed". For example, if most the the information a user (typically an information worker) is doing is in, they shouldn't have to leave Outlook to use another application to get related information or do a related task, such check the status of a task specified in an email or send a fax of a document attached to an email.

SharePoint has been used to build applications for a New Hire Process, a Project Management app for cross-functional (matrix) organization, a network sppt and monitoring solution, and Sales Generator. These rough apps were each built overnight by teams of three .Net developers trained for only one day in SharePoint.

CRM Live, at $60 per user, might be a good option for sales force automation (SFA) needs of most small to medium sized businesses. See http://crm.dynamics.com/ for more information.

Gartner recently announced MS BI Platform is now in the "magic quadrant" of being an industry leader. It is matching up well against big players like IBM/Cognos and Oracle. Microsoft's strong recommendation is to use Excel and Excel Services as the end-users BI tool. Report Services can be difficult to implement due to multiple security layers. For the first BI project, put all software and data on one machine and go for the smallest data domain possible.

Speakers recommended a number of tools, templates and helper applications on CodePlex. CodePlex was likened to SourceForge for Microsoft apps. See http://www.codeplex.com/Project/ProjectDirectory.aspx?ProjectSearchText=moss for an example of user contributions for WSS and MOSS SharePoint development. Most teams should first review what's out there before building any new applications.

What companies can do with these new tools and functionality depends on their company's priorities. Key performance indicators (KPIs) and actions items could be:
1. Increase revenue - Leverage the AdSage\AdCenter Excel Plugin for keyword and campaign analysis. See http://advertising.microsoft.com/advertising/addin-demos .
2. Control spend - Automate and simplify expense reports
3. Gain customers - Flow customer feedback to site and Customer Service into key performance indicators and analytics
4. Retain existing customers - Automate reports on customer email, comments or other Customer Service data capture of feedback
5. Increase productivity for Sales, Operations, SEO, Editorial, Customer Service and IT
6. Streamline 3rd party interaction and interfaces
7. Automate and simplify business reporting with scorecards and key performance indicators
8. Allow drill-down and trend analysis of business data

The 2007/2008 toolset allows a greater ability to deliver on all of these items.

Resources from Code Camp Presentations

Below are links from my presentations this winter at Code Camp.

The outline for the presentation Improve Your Management and Leadership is located here.

The books referenced in the presentation are:

• Marcus Buckingham's First, Break All the Rules,
• Now, Discover Your Strengths, and
• The One Thing You Need to Know.
• Jim Collin's Good to Great,
• Ken Blanchard's One Minute Manager and
• Andy Standley's Making Vision Stick.

I also referenced Patrick Lencioni's Five Dysfunctions of a Team.

All of these authors have spoken at The Leadership Summit and their presentations may be available through that store.

I also briefly mentioned a book on metrics. My blog post on that is here, and the book is Five Core Metrics: The Intelligence Behind Successful Software Management.

The outline for Sunday's presentation Combine Agile with Your Strengths is located here and the slideshow is shared over the web on SlideShare here. The books mentioned include First Break All the Rules and Now Discover Your Strengths, linked above, as well as StrengthsFinder 2.0 and Go, Put Your Strengths To Work (on Google Books, so you can read parts of it).

I previously wrote a fairly thorough summary (certainly not an elevator speech) of the business value of using a strengths-based approach here.

Don't Know What You Got ('Til It's Gone)

I've recently had the opportunity to see what's lost when a team goes from Scrum to...something hard to define - general milestones and high level requests to get things done. I'll list the pain points.

What's Lost:

1. Visibility. The primary stakeholder doesn't really know where the project is. That's why he's having to ask several people throughout the day what their status is. But what good is asking them how it's going? It's very difficult to be objective, and their attempts are relative. "It's going well." Compared to...where you were yesterday? The non-existent schedule? The estimates before all the late changes came in, or after? Missing the deadline by a mile, and now thankfully looks only by weeks? Scrum records status and progress daily and more importantly the use of burn down charts track the trend!
2. Clarity. Are the people asked normally optimistic or pessimistic? Good estimators or bad? Ones who include code dept, deployment time, or just unit test and throw it over the wall? Our Scrum estimates were hammered out by group conscience (via planning poker) and we defined and standardized "done" via a "done is" checklist.
3. Teamwork. The team is now divided and fighting against themselves due to individual developers getting pulled by different business owners for different projects. Developers either don't help each other, or if they do, are chided for not exclusively working on some other "priority" project. The real problem isn't the developers. Scrum provides a framework to help the business in defining THE priorities in sequence, as well as defining who the one product owner is whom can dictate where the resources (developer hours) should go.
4. Motivation. All these issues combine to undermine motivation (a classic mistake, per Steve McConnell). Working towards a difficult deadline, without milestone deliveries to celebrate and foster hope, without real teamwork and interdependency, and without laser-like focus on the goal, motivation dries up. And then work becomes a grind, negatively breeds and a downward spiral of self-fulfilling prediction of an unreachable goal takes root and grows. Left alone, the business reaps nothing but failure for their investment, and the hours and days and weeks of people's lives are wasted on a harvest of the bitter fruit of failure.

What Is SharePoint?

Microsoft provides a set of functionality called Windows SharePoint Services, now on version 3.0, within Windows Server 2003 that is free to use. This free group of services provides document collaboration, information-sharing, list creation, Web page creation and related services. It is very useful for workgroups, departments and other small groups of users to work together on a set of documents, share information and otherwise collaborate.

Microsoft Office SharePoint Server 2007 is the new version of SharePoint Portal Server (combinging Microsoft Content Management Server) and provides additional functionality for business intelligence, business process integration, enterprise search, enterprise content management, and personalization.

The most common uses of SharePoint that I've seen are:

1. Creating team sites where only certain project team or department members can login, see, edit and add information and documents
2. Creating lists of information that can be easily customized by adding new columns, value lists and multiple filters
3. Setting alerts on information or document areas so that all team site users receive an email notice of information added or notified.
4. Using issue lists that email the assignee of the issue of any change with a before and after summary of the change, as well as keeping a history of comments on the issue.
5. Using document libraries (lists) that allow version histories of the documents, including checking in and out, creation of folders for organizing groups of files, and an Explorer-type view that supports drag-and-drop.

The types of business uses I've seen include:

1. Tracking employee hours, including using a lookup of tasks to choose from so that information is always correct.
2. Data entry of metric data that drives other graphical reports
3. Letting teams have their own designated and central area for their documents and other information
4. Creating a business process of several required steps
5. Using the discussion functional to capture a conversation thread of multiple users on a document posted to the team site.
6. Using a modified issue list to categorize, prioritize, track, assign and drive issues on a project, as well as quickly export the list to Excel and send to additional outside users.

There are Microsoft partners that run SharePoint Services as a hosted service, lowering the barriers of complexity and effort for small and medium business to try out the functionality and see if there a good return for the money.

Agile Project Estimation w Scrum Planning Poker

I learned this week that planning poker is a big return for the small investment. I could not find planning poker cards in stock anywhere in the world, until Mike Cohn just made them available again (http://www.mountaingoatsoftware.com/products/cards).

Besides all the great benefits outlined in Mike's great book on Agile Planning and Estimation, I found that the team interaction was good. There were great alternative views and just an overall good feeling of everybody's opinion counting.

The Leadership Summit - Session 1 - A Vision to Die For

The Leadership Summit
Notes from Session 1 - A Vision to Die For, Bill Hybels

Vision must be owned. Ownership is the most powerful weapon in casting and maintaining vision for your organization. It's the painting of the picture that brings passion out of people. It ties into purpose – a sense of destiny beyond to 9 to 5.

Hybels referenced the book of John – Being an owner vs. just a hired hand.

"I am the Good Shepherd. The Good Shepherd puts the sheep before himself, sacrifices himself if necessary. A hired man is not a real shepherd. The sheep mean nothing to him. He sees a wolf come and runs for it, leaving the sheep to be ravaged and scattered by the wolf. He's only in it for the money. The sheep don't matter to him." - John 10:11-13

Hybels challenged us to ask ourselves, "At my current workplace, am I the owner of the vision, or the hired hand?" Do I pray for it, protect it, volunteer for it. Owners of the vision will sacrifice deeply. They will be high capacity workers.

Hybels then referenced a group that was an owner of a vision. On March 7, 1965, a group of civil rights marches left Selma, Alabama for Birmingham. They made it as far as the Edmund Pettis Bridge. There they faced state troopers and county sheriffs armed with billy clubs tear gas and bullwhips. The lawmen attacked the peaceful protesters and drove them back to Selma. This event became known as Bloody Sunday. Owners of a vision will be willing to die for the cause.

Out vision is so important. It should be bold, faithful, honorable, and clear. But vision needs to be owned by the people in our organization.

How do we do this? For some Type-A leaders who live on blazing a trail and calling back to everyone to follow their lead, it's a four letter word: P-R-O-C-E-S-S. Without process, we defeat every one left out (which is everyone but the leader).

There are three steps in the process for vision ownership:
1. Vision Formation
There is the top-down approach (bad), or the team approach (good). The top down approach is so often taken because it is quick, but doesn't take, doesn't hold.

The recommendation on the team approach was to have an offsite, with the focus being the question "What should our organization look like in five years?" It may feel slow or inefficient, and to some quick-acting leaders like "swimming in peanut butter." But this builds community, value and more likelihood of ownership. The team members may not always have their way, but they at least need to know their ideas have been considered.

2. Vision Refinement
Make a first draft of the vision. This crystallizes it, even in draft form. Take this draft to the groups at the next level out, trying to get different types of groups, feedback. Ask what's clear, what's confusing, what excites you, what scares you. The goal is to come away with a crystal clear, compelling vision.

3. Vision Declaration

Introduce the vision in front of leaders first, asking if it is clear and compelling. The declaration is not a solo effort, but a team activity.

Great leaders know that more time in the vision casting process increases ownership. Vision leaks, but don't berate the workers for this. Use any tactics to keep refilling the vision. And remember to celebrate progress.

Meeting Rules for Daily Stand-Up / Daily Scrum

For the team:

1. Arrive on time or early.
   
2. Be ready to say what you did yesterday and what you plan to do today.
   
3. Keep your report specific, precise and short in order to help the meeting end within 15 minutes.
   
4. Listen to other team member's status in case it might relate to your tasks or impact you.
   
5. Don't interrupt people when they are talking.
   
6. Don't agree to decisions or action you don't understand. Ask questions and insist on answers when you need clarification.
   
7. Note the tasks or action items you volunteer for.
   
8. If you raise an issue or question that can't be resolved in a minute, ask to discuss with the parties involved after the meeting.
   
9. For those calling in, be sure to start your report with "This is [your name]."
   

   
    

   For ScrumMasters:
   

10. Be sure to have (or have access to) your relevant information (the sprint or product backlogs, the software being developed, or the project, requirements or design documents and code)
    
11. Be sure to have (or have access to) the phone numbers of any team members who you are conferencing in.
    
12. Be sure to have scheduled the recurring meeting and invited all appropriate people
    
13. Be sure that the invitation includes the relevant information, such as meeting location, project site URL, and conference number.
    
14. Be sure the invitation subject line is specific (for those involved in multiple projects).
    
15. It is your job to keep the meeting focused and starting and ending on-time.
    
16. It is your job to know why and how scrum works. Look for teachable moments in the daily scrum.

Why Scrum Works

Just finished the book Project Management with Scrum, and it is excellent.

Here a great overview quote from the forward:

"Gary Convis notes that Toyota's sustainable success comes from an 'inter-locking set of three underlying elements: the philosophical underpinnings, the managerial culture an the technical tools. The philosophical underpinnings include a joint [worker] , customer first focus, an emphasis on people first, a commitment to continuous improvement...The managerial culture...is rooted in several factors, including developing and sustaining a sense of trust, a commitment to involving those affected by first, teamwork, equal and fair treatment for all, an finally, fact-based decision making and long-term thinking.'


Scrum works for all the same reasons. Its philosophical underpinnings focus on empowering the development team and satisfying customers. Its managerial culture is rooted in helping others achieve their goals. Its technical tools are focused on making fact-based decisions through a learning process. When all of the factors are in place, it's hard for Scrum not to succeed. - Mary Poppendieck"


From Agile Project Management with Scrum (Microsoft Professional).