I was recently sent a question that I've heard before. It's important, and I think my view (as someone with strengths Relator and Strategy) is not one I've seen much in the workplace. So, I thought I'd share the question and response with you. I hope it is of some value.
Question: Given a development team that is fully convinced of adopting the Agile methodology, what is the best way to get buy-in of upper management that is used to having hard deadlines and deliverables similar to what (allegedly) was delivered by waterfall methodologies?
My Response:
Good question, and I have a couple thoughts.
First, it would be nice if you could dig up even a few facts about what's happen in previous projects. Often I go through email from key people at milestones or deadlines and build a simple journal of events. It helps keep the facts simple and clear in my mind for when there's a key decision-making meeting later (I tend to lose my train of thought or important facts in those pivotal moment).
That ties into my bigger view, which is that my experience in winning others over starts with a focus on a short study of those people, and only after that, what their objections or concerns are. Often times "the issue isn't the issue." All problems are people problems, so focus on the person. It's likely the decision for this person is not about facts, but about their fear, uncertainly and doubt.
So, if they have their neck on the line, you present agile as a great risk-mitigation method (and let me know if you need the info on why that is so). Or if they need some wins with key management/peers in the company, present it as the best way to get game-changing features out, and out sooner. If getting stung by poor quality is the issue, take the approach of quality built in upfront.
Practically speaking, they are usually only concerned (or focused) on one or two aspects. Keep it simple and address those. If you're not sure what those are, we can talk about fairly simple ways to get at that information.
Also, I keep in mind a couple of personal aspects. First, natural law. You have to make this agile adoption a win for them *personally*. They have to believe at some level that you're looking out for them *personally*. This builds trust and that trust gives you political capital to get things going and get things done.
Second, they have a personality and strengths that incline them to look and interact with the world a certain way. The simplest paradigm is from Management By Strengths. If they are "me" centered, it helps to present information/options/decision in a succinct way that allows *them* to make the decision (rather than be told something like "This is obviously the right thing and we need to do it," no matter how earnestly you deliver it). If they are "we" types, present it as a something the whole team (whatever he sees as team - project, department, etc) will benefit and be a part of/involved in. If they are "pace" types, you have to deliver the information and decision points clearly, gradually over time. Those types can't be hurried to make a decision to get out of a burning house. Be willing to invest in being patient, consistent and clear in your message. If they are a "process" type, present more as a clean system and process approach, not some foggy, no-documentation devs-gone-wild weirdness that they might have heard. Give them the white papers and research from Microsoft, IBM and other respected companies.
There are certainly other personality/problem aspects, but I hope this is enough to get you started. A good patterns approach to bringing change to an organization is Fearless Change. You can flip through and find ideas to apply immediately.
Wednesday, August 11, 2010
Monday, May 24, 2010
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
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
Friday, May 21, 2010
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
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
Wednesday, May 05, 2010
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
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
Monday, March 29, 2010
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.
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.
Tuesday, March 23, 2010
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 :
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 :
- That they know, understand and practice the Scrum framework
- That they are aware of where they aren't, the possible consequences, and the limitations (domain) of Scrum
- That they know, understand, and are living the agile principles, Scrum values and self-organization
- That they are aware of other agile methods and the pros and cons
- That they are connected to community and learning sources
- That they gel and are moving forward as a team
- To understand why management wants Scrum/agile here
- To know their definition of success
- To understand what they see as their opportunities and challenges
- That I set and meet expectations each week
- That goals are stated and progress visible
- That goals clearly align with my customer's goals
- That I understand what it means to meet and exceed expectations
- That I understand what will help them move forward, and have contributed to that
Monday, March 15, 2010
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:
And I particularly loved this approach with management, and of course their results overall:
Technorati Tags: agile, kanban, lean, scrum
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.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.
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.
Technorati Tags: agile, kanban, lean, scrum
Tuesday, February 16, 2010
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
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
Sunday, January 31, 2010
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
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
Tuesday, January 26, 2010
Salesforce.com's Success with Agile
Perhaps the best slideshow I have seen on agile implementation\agile adoption in the enterprise.
Technorati Tags: agile, scrum, management, saas, web2.0
- 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?
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
Saturday, December 19, 2009
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
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.
Thursday, November 05, 2009
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
[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
Wednesday, October 14, 2009
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
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
Thursday, September 17, 2009
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
Sunday, August 09, 2009
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
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
Tuesday, July 14, 2009
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
Technorati Tags: agile, scrum, kanban
Trackback: http://www.typepad.com/services/trackback/6a00d83452ee9169e2011571fcf307970b
Saturday, July 04, 2009
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.
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.
Wednesday, April 08, 2009
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?
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?
Saturday, January 31, 2009
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:
* Data requirements
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).
Scenario 1: Description of Scenario
Story Card Description
The 2-3 sentence version of what the card is aboutBusiness 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
- Step 1 to demonstrate the criteria
- Step 2 to demonstrate the criteria
- Step 3 to demonstrate the criteria …
Tuesday, November 18, 2008
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.
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.
Subscribe to:
Posts (Atom)