Agile Tool: Trello

Capture

If you are anything like me, I’m always looking for great agile tools to add to my arsenal.

I stumbled Trello the other day and I must say I’m pretty impressed! So far I can say that it’s great for personal Kanban or small internal projects. And it’s free!

Notable Features: You can easily invite people into your boards to collaborate,  view version history, add pictures to cards, and create custom lists. There’s a guided tour function that is really helpful to give you a jump start into using the tool.   Another feature I think is really helpful is the ability to create check lists within a card.  This would be a great way to keep track of tasks within a story.  My personal favorite feature is the ability to add a deadline to a card…So helpful for planning out a light weight project or really any small effort needing coordination.

Enterprise Use: From what I can tell this would not be a great Enterprise tool due to some features missing like rolling up cards into epics or portfolios.  I’ve heard this same feedback from 4-5 colleagues.  However, my observations are based on the free version, not some of the paid options they have, which very well could have those additional features.

Personal Use: I created a board for a home projects and invited my wife to the board.  We can both individually add projects or honey do’s and change the order of the stack rang for our backlog. (It’s fun to see how we have different priorities 🙂 )  The mobile app works quite well and does pretty much everything I would want it to do from my phone.

Conclusion: If you are looking to get more organized and incorporate some of the agile principles into your life and work, Trello is worth checking out!

Image source:  Trello.com

How to measure success in an Agile organization

**Re-posted from https://www.slalom.com/thinking/how-to-measure-success-in-an-agile-organization where this article was originally published.

Any organization adopting Agile faces the challenge of figuring out how to measure success. “How will we report to executives?” and “How can we standardize reporting across multiple teams?” are some of the first—and most important—questions that pop up. Answering these questions without compromising the spirit of an Agile transformation is critical to adoption.

Why? Because every metric you put in place will generate some type of behavior, be it positive or negative. That’s why it’s imperative to exercise a vast amount of diligence when working to define your metrics.

In the world of Agile, success can look very different than it does in a traditional Waterfall, fixed-scope environment. One of the cornerstones of Agile is to work on what’s most important to the business and deliver value as soon as possible. Here’s an example: the team goes into a sprint or release and commits to completing five items. But after work begins, the team learns that the number-one priority will require much more work than expected due to new requirements or bugs discovered during development. Poor planning isn’t to blame; the team just has to make adjustments based on new information. Everyone agrees to focus on the number-one item to complete by the end of the sprint, leaving items 2-5 unfinished. They refocus, successfully complete item number one, and deliver it on time. But the team only delivers 20% of its expected scope at the end of the sprint.

To many Agile teams, this could be considered a complete success, because ultimately the percentage of original scope isn’t as critical as delivering on what’s most important. So in this scenario, the traditional measure of committed vs. completed can be a poor measuring stick.

Let’s look at what could happen if the success of this team was measured by what it completed. The team learns that good numbers are more important than delivering on the top priority. They then start padding their estimates to ensure that they have plenty of time to finish without any risk of backlash. Now you have valuable energy being wasted on navigating a process rather than getting things done. You’ve invited some of the more negative aspects of the Hawthorne Effect to come and run rampant on your project and team.

For an Agile organization to be successful, there has to be a general assumption that people are working hard and want to do their best. The role of a good leader is to enable teams to work smarter, not harder.

Here are seven traditional and not-so-traditional ways to measure the success of your Agile team.

1. Measure teams rather than individuals. A study conducted by Team Builders Plus found that “individual performance data are of less value (judging from the ratings and number of organizations tracking it) while team data reinforces collaboration and problem solving.” Collaboration is a key part of any Agile team that focuses efforts on the outcome of a project rather than a single person’s output.

2. Keep track of the percentage of the highest priority items being delivered. If your team’s focus is on delivering what is most important first, you can keep track of this trend over time. If the team is always delivering on priority two and three, but missing number one, you can use it as a coaching opportunity to help increase collaboration.

3. Measure the team’s satisfaction. You can be leading a team that is delivering at a high level, but if they’re miserable, you’re in a dangerous place. Part of a team’s success is the overall satisfaction of its members.

4. Evaluate your software. There isn’t a universal solution for determining if you have “working software.” Some of this relates back to customer satisfaction, but you could also measure if the work being done is truly solving problems—or if, in fact, it’s creating more.

5. Show the business value delivered. This may require more work up front, but if you have an idea of the value for a particular story or project, you can tell the story of the value that was delivered.

6. Provide a narrative, not just data. Why spend time collecting, packaging, and sharing data that really has no bearing on a team’s success? Sometimes even providing 3-4 sentences can give much more useful information than a pie chart. Visualization of data is definitely a good thing, but think carefully before defaulting to visualizations.

7. Measure anything the business says is important. Easier said than done, but as a guiding principal, focus on what the customer is saying is important. If they only care about 2-3 things, why give them 15?

Now you’ve got the metrics, but what do you do when ground forces at the executive level are resistant to Agile? First off, don’t react when people are critical or have a different perspective about what should be measured. You’ll be more successful showing people how Agile can enable the metrics they want.

Of course, there’s still a chance you won’t be able to reconcile the expanse between the pro-Agile and anti-Agile parties. In VersionOne’s annual Agile survey, 53% of people said an organization’s inability to change its culture was a barrier to adoption. There’s no silver bullet here. Another revealing statistic from that same survey was that 35% said trying to fit Agile into a non-Agile framework was a barrier to adoption. The research speaks for itself:you can’t always expect the metrics that work for a Waterfall project to apply to an Agile project.

The workplace is full of spreadsheets and databases, amassing ever-increasing amounts of information. With that, the definition of success—specifically in information technology-centric groups—has changed dramatically over the last 10 years. I’m a firm believer that success in its purest form can be measured by how happy your customer base is with the product or service you provide for them. That’s why the Agile Manifesto emphasizes “individuals and interactions over processes and tools.”

Brainstorming, Story Boarding, and Retrospective Tool – IdeaBoardz

This week I was talking with some fellow colleagues about starting a Lean Coffee for our organization.  We have a national (soon to be international) footprint and a ton of knowledge out there, but how to bring it together?  So I thought the lean coffee meetings would be a great way to bring people together to inspire, encourage, equip, and empower each other. It could also create a consistent venue where we can work together to solve challenges for our clients.

I had a few different people suggest using a tool called IdeaBoardz.  I want to share this tool not only because think it will be great for Lean Coffee but it has value for things like brainstorming, story boarding, and retrospectives.  Especially if you have co-located teams.

It’s simple to use and has just enough functionality to make it useful. And best of all…it’s Free!

You can take it for a test drive without having to sign in or create an account.

IdeaBoardz

Please Note I am in no way affiliated with IdeaBoardz and receive no compensation for writing this article.

MBP #1: Become More Agile By Doing Less

Micro Blog Post #1:

Capture

What Is An Agile Process? An agile process is simply ANY process that adheres to the principles of the agile manifesto. When the founders of the Agile Manifesto got together to create it and the principles, they asked what they were doing right. When working to continually improve do not simply focus on what where you need to improve. But look at what you are doing right and try to do more of that. Keep it simple and your agile teams will flourish. Becoming more agile doesn’t necessarily mean introducing more processes, it could just be focusing more intently on what is working.  Who knows, maybe you can become more agile by doing less.

Stay Agile My Friends

ckv31a

This is mostly meant to give you a chuckle, but there is some validity to it as well.  In my last blog post I talked about how we need to challenge the limits of what we understand agile to be.  Can you be agile and waterfall at the same time?  Probably not if you look through the lenses of what we typically view as a waterfall process.  But it’s possible.

One thing I’ve noticed as an agile coach is that people like to gravitate towards what they know and are more comfortable with.  One way this can play out is when helping a team adopt agile, you can get a strong pull to keeping things in the box of a waterfall process. This happens both at the individual contributor level and management level. Management can sometimes want waterfall type metrics but without the changes needed to realize the true benefits of agile. It’s ok though.  Be patient, and see if you can find a way to meet somewhere in the middle. Waterfall isn’t bad.  In fact it has tremendous value in the right context.  So, as an agile enthusiast make sure you aren’t always negative about waterfall especially when it could be used to your advantage.  However, what you don’t want to do is fall into the trap of using the buzz words from agile/scrum but keeping things pretty much the same.

I’ve found it is helpful to ask people questions about why they want to do something a certain way. “What do you think will be the benefits of trying it this way?” “What are you hoping to accomplish by doing it this way vs. that way?” If you say things like “You are just stuck in old thinking.” or “That’s not agile.” you can build walls instead of creating bridges. If they are pushing for trying something, maybe just go with it for 1-2 sprints.  Then evaluate the impact it is having.  After all, I’ve always found that I am continually learning from the teams I work with, and surprise-surprise I DON’T KNOW EVERYTHING!  😉

“That’s Not Agile”

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?

Agile Certifications…What’s The Value?

Scrum certs

Last week I attended an agile training seminar for the Certified Scrum Master (CSM) certification. It got me thinking about what is really the value of going to an agile training session.  Having already attended the Certified Scrum Product Owner (CSPO) training last year I was curious as to how much I would benefit.  When I attended the CSPO training the trainers take was that you needed to learn almost as much about the scrum master role as you do the product owner to be able to understand better. I have to say I was pleasantly surprised with the amount of new knowledge I walked away with. I’ve noticed that each trainer has had a deep background leading and coaching agile teams, and with that comes different nuggets of wisdom. While the first 1-2 hours were mostly review, after that it seems that each session had a life of its own and had tremendous value.

Do you really need an agile certification to be effective on an agile team?  Technically no. But if you are someone who is looking to make a role transition or have an extensive background in waterfall environments, it could be a great tool and demonstration of your ability to make that transition. Obviously time and experience with agile is more valuable, but if I were going to make a statement in the same format of the agile manifesto it would look something like this “Working experience over training seminars and certifications.  That is, while there is still value in certifications, there is more value in working experience.”

Why should you keep going to training seminars like this? For me I realized that when you work in an agile organization you can start to get used to the way you are doing things.  And being with a room full of people talking about what they do gives your copious amounts of inspiration for what you are doing. I was furiously writing out sticky notes with ideas for things to try, and now the challenge will be slowly introducing some of those ideas to the team without being “that overly hyped out conference high let’s change everything” guy.

Something else I was pleased with is that after attending the CSM training I was required to take an exam (open book), that required me to prove my knowledge. It didn’t sit right with me that I could attend a 2 day CSPO training and leave with a certification.  The CSM exam was actually pretty challenging, even with the internet at my disposal.  It was a good exercise all in all.

Apology to the internet and an intro to the blog

Dear internet and devoted bloggers, I’m sorry.  I occasionally write some blog posts on my personal blog, but for the most part I’ve been one of those who consumes but doesn’t contribute.  Have you ever thought while searching for something “I really should be one of the people that posts helpful information on the internet and not just the one who searches for it.” ???  Well…I have too, for many years, and that’s part of why I am starting this blog.

I’m a project manager in the Seattle area working at a consulting firm.  In recent years I’ve been working with agile team more and more, and know I’ll have some information others might find useful. I’ve developed such a strong interest in agile/scrum that I’m going to get of my keyboard butt and write!

I’ll be posting about practical everyday tips for agile teams, my experiences with different training resources, agile memes and will even have guest bloggers from time to time.  Hopefully we can keep a lighthearted and humorous approach to solving real business problem.

Thanks for stopping by The AgileSphere!

-Chris