Archive for the ‘How-To Apply Agile’ Category

The Decline and Fall of Agile and How Scrum Makes it Hurt More

Sunday, November 16th, 2008

James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile.  Please please please (pretty please) read it before you read what I am about to write here!  I agree with what James is saying 100%.

Now, let’s hear the truth:

Scrum is really really hard!  Doing Scrum well is like quitting a heavy, long addiction (I think).  Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).

Doing Scrum properly takes:

sacrifice – sacrifice of our ways of thinking, our habits, our comfort

wisdom – wisdom to see the small improvements while struggling with the humongeous ones

and most importantly,

truthfulness – honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy

Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change.  Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.

But Scrum isn’t the only “agile” method.  As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical.  Do they have to be done and perfected first?  No.  But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.

As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard.  This is why my training class is three days instead of two.  This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters.  This is why after the first day of my course, most students are actually feeling quite discouraged!!!  It takes three days minimum for people to understand and process the incredible shift in mental model.  And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.

So what should people do?  Do Scrum by the book.  Yes that means putting a whole team in a single room.  Yes it means that you have to really remove obstacles, and fast!  Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers).  Yes that means that it – will – take – a – long – time – to – get – it – right!!!!

And please, it is so worth getting help beyond just the training!  If you think that I’m just trying to promote my own coaching services, please go check out:

www.ccpace.com

www.rallydev.com

www.outformations.com

www.lithespeed.com

www.mountaingoatsoftware.com

www.controlchaos.com

www.bigvisible.com

www.kittyhawkconsulting.com

They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

The Importance of Questions

Tuesday, October 28th, 2008

I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.

I then suggested that she compose a reply email containing the same set of questions.  Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a few:

First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.

Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Book Commentary

Monday, September 29th, 2008

AGILE Project Management with Scrum -A book by Ken Schwaber

Prior to the Certified ScrumMaster seminar I attended in August 2008, I read the book by Ken Schwaber called Agile Project Management with Scrum based on a recommendation from Mishkin Berteig.    After attending the seminar and becoming certified as a ScrumMaster I re-read the book.   The second reading was much more valuable than the first for I had a much better understanding of Scrum.   Here are my comments on this book.

What have I learned?

1.    The adoption of Scrum methodology is more about changing roles and behaviours than it is about embracing a new process.

It was obvious to me and to Ken that one of the greatest challenges facing those individuals when moving from a their current environment to a scrum environment was that they would need to change their behaviours.    In the former environment the team member would be directed and inspected based on what their project manager told them to do.  The PM is the boss and the team members are somewhat powerless.  In Scrum the team members take responsibility for their commitments and communicate their accomplishments on a daily basis.  The hardest change occurs when the project manager is asked to become a ScrumMaster.  The project Manager is familiar with assigning tasks and personally inspecting results. In the scrum environment they are the servants of the team, removing obstacles and facilitating the process.   As Ken states in this book some project managers have great difficulty transitioning into the ScrumMaster role.  They are unwilling to give up the power and position as a project master.   It is hard to move from the leader of the pack to become the sheep dog herding the sheep!

2.    Scrum is unforgiving for if you do not apply the fundamental principles it is likely your efforts to adopt Scrum will fail.

As I reviewed the numerous case studies Ken chronicled is was apparent that when organizations, Team members, Product Owners and ScrumMasters followed the terms, conditions and guidelines of the Scrum methodology, they tended to deliver on their commitments.   When they misunderstood, misused or deleted some portion of the methodology they tended not to accomplish their objectives.   The methodology is well thought out and works in many situations when used appropriately.

3.    Scrum enhances individual and team expertise.

I agree and totally support Ken’s opinion about the value of Scrum.   I have no doubt the individual team member is empowered and has a greater sense of achievement.    Obviously based on his case studies, Ken builds a strong case that Scrum allows the team to deliver quicker.  The process is more change adaptive, responsive to customer needs, timely and economical than traditional methods.   Greater energy and capacity is released in the team and individual team members.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Why we like working at Berteig Consulting

Monday, September 29th, 2008

From Paul Heidema:

Most people despise the end of Sunday. This means that Monday, the dreaded start of the work week, is just around the corner. Most people don’ have a team that they trust at work. Most people are unable to be truthful with their boss, or even truthful with themselves about their work.

Fortunately, I am not one of those people. I work with great people. They are kind, honest, caring, and very professional. I work at Berteig Consulting. My team is made up of four people, one of which is me. Travis, who is very gifted in the arts is also very professional and down to earth. Mishkin is an ideal boss who cares deeply about his co-workers, and treats us all like brothers and sisters. Laila is pure and able to make others feel completely at home (she is also my wife).

I never know what will happen each week but I do know that I will be happy and enjoying the experience with such a wonderful team.

From Mishkin Berteig:

Every day that we start work, I’m happy to be here.  It’s a bit cliche, but I love the people I’m working with.  I also love the work we are doing.  The vision of the company is maturing and our focus on education has already changed the way some things are being done.  I like our work environment: there are three of us “crammed” into a small office room – we are constantly collaborating, discussing options and problems and reminding each other of work to do.  Hiring Laila to work with us part time has been an incredible change.  She thinks systematically about our way of working and makes suggestions in such a loving way that it is impossible to feel like we were even doing anything wrong in the first place.  For me personally, having Travis focus on the role of Process Facilitator (ScrumMaster) has also been a huge relief for me.  He keeps us in line with a lightweight agile process and I’m loving it!!!  Finally, for me, focusing my own efforts on business value has been great – with the help of Paul, Laila and Travis, I now have the mental space and the actual time to devote to this critical part of running a business.  I’m still learning like crazy, and it’s great fun!  I wish everyone could work in an environment like this… which is, of course, why we offer the services that we offer! :-)

From Travis Birch:

At Berteig Consulting, we practice Agile.  I am currently working in the role of process facilitator for our new team of 4.  We work in 1-week iterations.  As a couple of the team members have a 4-day work week, we have our retrospective on Monday mornings at 10 AM, followed by the planning meeting for our next iteration at 11 AM.  The remaining work days begin with a daily stand-up meeting using the reporting methods of a daily Scrum (each member reports 3 things to the team – “What I did yesterday”, What I’m doing today”, and “What are my obstacles”).  We work in a collocated team room, with items, tasks, obstacles, definition of done and burn-down chart all up on the walls.  We just completed our second iteration.  As part of today’s retrospective, team members actually did some demos – Mishkin showed us some of the great changes he’s made to his course material and Paul demoed our beautiful newsletter.  Laila even demoed some travel tools that she’s been working on for the trainers.  We also decided to each write our reflections in order to share them with those who might find it useful as a way of wrapping up the retrospective for this iteration.

Visibility of work and openness of consultation feeds an overall feeling of excitement and optimism in the team!

From Laila Heidema:

Having worked at Berteig Consulting for merely two weeks, I already feel that I am part of a team. I feel that I am contributing in helping people with their business in an environment that is creative, supportive, joyful and cooperative. I know that each week will bring interesting new tasks that will not feel like a mundane set of work, or carried out in order to finish the week. Rather, each project is completed with a sense of contribution towards the company’s quest to be the best corporate educator for humanity. Were it not for Berteig’s positive atmosphere and team dynamic, this would not be possible.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Command Scrum – Productivity at What Cost?

Tuesday, September 16th, 2008

I highly recommend reading two articles about the possibility of imposing Scrum on a team and what the results are of doing so.  The first, an article titled “Shock Therapy” by Jeff Sutherland with an extensive report from Scott Downey of MySpace.  The second article, “Shock Therapy or Compassion” by Tobias Mayer, provides a thought-provoking alternative view.  The only addition I would like to make is just to ask a simple question: is everyone motivated by the same thing?  I suspect that the knee-jerk reaction is a big resounding “no”, but I ask you, my gentle reader, to consider more deeply.  Does anyone really get satisfaction out of purposeless work, no matter the other rewards?  There is a strong case to be made that in fact humans thrive on solving meaningful problems… problems that are meaningful to themselves, their community and to humanity in general.

I would also like to point out some coaching models that often start with short term pain, discomfort and even a strong desire to rebel: a personal trainer at a gym, a business coach, a life coach, an executive coach, etc. etc.  The trick is, of course, that you get into the coaching voluntarily in the first place.  You put yourself in the coach’s hands and trust / suspend disbelief for just a short time while the coach helps you go through the discomfort.

It takes a good coach to make this work.

The benefits are huge.  Anyone who has made it to the other side of that discomfort knows this.  Anyone who hasn’t made it to the other side is going to be understandably skeptical.

So is what Jeff and Scott are describing really “command-and-control” Scrum?  Is it breaking the principles of Self-Organizing teams?  I don’t think so, but how about you?  What do you think?  Do you think you would be better off or worse off with this sort of “help” with starting Scrum?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Great Blog: Lean Software Engineering

Tuesday, August 26th, 2008

Christian Gruber pointed out a great blog to me today: Lean Software Engineering.  I’ve read a few of the articles and I like them.  I don’t agree with every detail, but I’m pretty happy with what I see there.  In particular, I really liked the article on using a Priority Filter.  The idea of a priority filter is a great operational technique but it makes it difficult to clearly justify the cost-benefit of doing the work.  Picking the highest priority item from a set of items that all have a negative return is still a bad way of working.  The technique could easily be combined with an analytical assessment of the value of a piece of work relative to the cost of the team (and any capital costs).

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Crystal Clear – A Book on Small Teams (pt. 2)

Monday, July 21st, 2008

Crystal Clear: Human-Powered Methodology for Small Teams - Book Cover

I recently started writing a book review on Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. Check out the first part of my review. I have read Chapter 1 entitled Explained (View from the Outside). It was a very interesting chapter that set Crystal Clear as the answerer to Alistair Cockburn. It made many aspects of the Crystal family clear in my mind. I enjoyed the questions, and the answers were insightful and helped me to put the ideas into a whole picture.

At the moment I am reading Chapter 2 entitled Applied (The Seven Properties). Frequent Delivery, Reflective Improvement, and Osmotic Communication made sense to me and aligned somewhat to my own beliefs. When I started reading the fourth property, Personal Safety, certain parts seemed fine, while others set off warning bells. I believe that the purpose of any team is to progress. This is achieved through trust, respect and unity.

Cockburn says “Once personal safety and amicability are established, a useful, playful dynamic may emerge. People may wage competition with each other. They may argue loudly, even to the verge of fighting, without taking it personally. In the case where someone does take it personally, they sort it out and set things straight again.” – page 31.

The statements above concern me. Cockburn addresses trust by saying that people will not take it personally. Respect is lost because they “… May argue loudly, even to the verge of fighting”. I would be unable to say that I respect someone if I yell at them or even raise my voice. Now unity is completely destroyed. For some reason our society and many societies around the world not only condone competition, it is seen as a way to judge attributes of excellence in an individual. This is not a good sign for our progress towards unity in human civilization.

I agree that being polite and not stating one’s opinion is harmful for trust. However, it is preferable to use consultation instead of competition. Imagine that a team is encouraged to compete with itself to achieve better results. Would there not be feelings of resentment or heightened levels of stress? Now imagine a team that is encouraged to consult and raise the team together without focusing on individual success. Would not this team feel excited to be around each other? Would they become fast friends and grow as a unit? Would family members of the team be enthusiastic to be included in picnics and socials?

Now the big question:
What is better, individual success or team unity that add value to not only the team but all who interact with them?

I will continue to read this book and post my reviews. I find it interesting that this book has helped to see the confusion that is happening all around the world in terms of progress, success, and human development.

I welcome any comments on my posts.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Crystal Clear – A Book on Small Teams

Friday, July 4th, 2008

I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.

I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.

I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.

What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile Tools vs. Agile Books

Wednesday, June 4th, 2008

Agile Tools vs Agile Books

I have been working with Agile for a few months. At Berteig Consulting we are using OpenAgile to run our small business. As such we try to use various tools to make our life easier. I have already mentioned that we use CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.

I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.

I am wondering if I am spending too much time on tools and not enough reading and researching Agile methods. I am enjoying reading about Agile success stories. Anybody know of small businesses that have documented or written about achieving success in Agile? Is there an Agile bible or maybe a book about the best ways to succeed using Agile?

So this is the question that I am wondering: Are tools better than books when it comes to Agile?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

The Scrum Study Guide is now Available… Really!!!

Monday, April 28th, 2008

Scrum Study Guide, “The Best Tool for New ScrumMasters”, is now available at Scrum Study Guide. This guide is designed to be an editable tool for helping ScrumMasters do their jobs effectively. With the Scrum Study Guide you are able to keep track of the rules of Scrum, to keep structured notes on your own job as the ScrumMaster, to maintain a list of online reference material, to assess the progress of your team, and to organize the obstacles you are working on.  It also contains a wealth of reference information for learning along the way.

This is the project I’ve been working on for the last several months that has reduced my output here on Agile Advice.  It represents a huge investment of my time as well as several other people who have assisted me in this including Paul Heidema and Garry Berteig.  Purchasing the Scrum Study Guide, aside from its usefulness as a tool itself, will also give you substantial discounts on other services offered by Berteig Consulting Inc.  Finally, if you like it, you can help to share it by letting us know who should get a discount on their purchase of the Scrum Study Guide.  Enjoy!

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Three Ways of Expanding the Scrum Definition of “Done”

Wednesday, April 9th, 2008

The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this? (more…)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Comprehensive List of Agile Practices

Sunday, March 9th, 2008

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses – if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices List (OpenOffice format – 68KB)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scaling Scrum and Agile – Seven Online References

Thursday, January 31st, 2008

I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.

(more…)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Patterns of Agile Adoption by Mike Cohn

Wednesday, January 16th, 2008

Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.  These Patterns of Agile Adoptions are described as three sets of contrasting options:

  1. Start Small vs. Go All In
  2. Technical Practices First vs. Iterations First
  3. Stealth Mode vs. Public Display
Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile Retrospectives and the Plan of Action

Thursday, August 30th, 2007

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb