Agile Scam – Abusive Comments… What To Do?

This is “my” blog – I write most of the articles, and it is owned by the business in which I am a major partner.  I recently was reviewing comments in the moderation queue and came across this “gem”:

This man is a scammer, agile snake oil only 600, what a bargain. Filthy scamming piece of crap, he’s probably stupid enough to believe his own s**t too.

I’m assuming this person, who is anonymous, is upset either about something I said here on this blog, or possibly something that I (or one of my colleagues) did while we were working with one of our clients.

Several months ago, I was also made aware of a posting about Berteig Consulting (and myself) on Ripoff Report.  I’m not going to link to it, but I will quote it here:

Our company undergoes Agile transformation. Our management decided to hire Berteig Consulting

- a bunch of charlatans spending hours talking absolute nonsense.

They promise sky rocketing performance because they teach us to ( than follows a great number of words with no meaning). We must reflect in Buddish manner, talk to each other, discuss obstacles, be truthful, play stupid games,…. They charge company big money for waisting employees time for endless meetings and providing us with useless information.

Honestly, these sorts of comments make me a bit sad, a bit down.  But here’s what I think about them.

The Agile “Scam”

Let’s make sure we know what we are talking about.  Agile is defined in the the Agile Manifesto.  If you aren’t familiar with it, please take a look.  Basically, the purpose of Agile is to find better ways of building software that are based in practice.  In other words, by people actually building software, and sharing their knowledge, experience and the values and principles that helped them do what they did.

The thing about values and principles is that they are a bit like axioms in formal logic: you can’t prove them.  They are a starting point.  So, if you read the Agile Manifesto and you happen to think that

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

is “Buddish” (whatever that is, presumably Buddhist), and that being “Buddish” is bad or useless, then that is certainly your right.  I can’t prove that this principle of the Agile Menifesto is “right” or “correct” or “always the best thing evar.”  But I like it.  I think it’s good.  I believe in it.  So I guess I am stupid enough to believe my own s**t.  Except that it’s not my own.  I didn’t write the Agile Manifesto.  But I do fully support it.  And, without exception, I think that if work environments tried to put in place the values and principles of the Agile Manifesto, the world would be a (slightly) better place.

So is it a scam?  Well, if it is, I’m being scammed too.  I work crazy long hours, and although I make a decent living, I’m certainly not getting rich off this Agile thing.  When I think of a scam, I think of “get rich quick” or “lose 20 pounds in 20 days” or those sorts of things that promise unbelievable results with little or no effort.

Unfortunately, Agile isn’t like that.  Here is how I think of three Agile methods:

  1. Scrum: incredible results at the cost of incredible pain.  This is kind of like I imagine detox.  An organization is near death and needs to be revived so extreme measures (Scrum) have to be taken.  Requires significant outside help.
  2. OpenAgile: good medium-term results that require significant investment.  This is kind of like making a conscious change from a poor diet with lots of junk food to a good diet: takes discipline, but do-able with good encouragement and support.
  3. Kanban: modest long-term results with relatively low effort.  This is like deciding to change only one thing about your health at a time even if you have lots of health problems.  Lots of small wins accumulate over time.  Doesn’t require much outside help.

Of course, my descriptions of these are _vast_ simplifications for the purposes of discussing the Agile “scam”.  Do professional sports teams or Olympic athletes need coaches?  Probably most people would agree they do need that outside help.  Is coaching sports teams or athletes a “scam”?  Nope.  Not all coaches are good, certainly, but coaching is an essential (sometimes difficult) investment to get to that level of high performance.

Bad Agile

Of course, not all Agile transformations or adoptions are good.  The Agile Manifesto is not easy for most people, teams or organizations to truly embrace.  One of the most common problems I see is that an organization believes that it can have distributed or remote team members and somehow have effective communication among those team members.  This is just one simple example that comes directly from the Agile Manifesto:

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

I guess, technically, the Agile Manifesto doesn’t out-and-out say that a team must be co-located, but boy-oh-boy does it ever make a difference.

And yet, doing radical collocation is damn hard for most organizations.  So lots of organizations try to adopt Agile techniques without collocation.  And, mostly, their results suck.  Or they try to do collocation, but totally botch it.

Any given principle or value of the Agile Manifesto has its own challenges.  And so most Agile implementations are distant echoes of the incredible results that some rare organizations achieve when they really get Agile.

My Track Record

As a consultant, coach and trainer, I sometimes wish that I could say that I have never failed, that I have never given bad advice.  That’s because in complex human systems, it is very very very hard to sort out cause and effect relationships.  If one of my clients fails to have a dramatic transformation is it because:

  • I gave bad advice?
  • Someone at the client subverted the transformation effort?
  • An executive didn’t support it enough?
  • Market forces destabilized the transformation?
  • The organization’s culture treated Agile as an invasion and fought it off?
  • Agile just wasn’t “right” for the organization?
  • Agile wasn’t adopted soon enough?
  • etc….

On the other hand, I couldn’t very well be a coach, consultant or trainer if I didn’t have a clue.  My colleagues, Paul and Travis (who are named in the Ripoff Reports article), and others whom I have worked with (Nica, David, Mike, Deborah, Christian, another Mike, Allistair, Holleh, yet another Mike,a Michael, and another Michael (wow!), Garry, Jim, Mark, Mary, Sanjiv, yes even another Michael, Julien, Brenda, Derek…) are all smart, experienced, sincere, helpful people… who all know what it takes to produce good results.

The “Secret” Essence of Successful Agile

And, strangely, the essence of it is encapsulated in just a few basic basics:

Truthfulness (vs. hypocrisy, lies and deception)

Collaboration (vs. competition or individualism)

Service to Others (vs. greed and apathy)

and, ultimately, love between people.

So.  To those two people who felt they needed to spew out their hatred, their pain, or whatever it is that they are suffering from, I encourage you to contact me directly.  My email address and phone number are public.  I can’t promise to solve your problem, but I will give you love and whatever help I can extend.

 


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Recommendations (Assessment and Playbook)

Recommendations IconWe have already written about how Leadership and Delivery Teams operate in a Real Agility Program.  It’s time to look at our Recommendations component: getting started on the right path for Real Agility.

Recommendations = Assessment + Playbook

In the assessment portion of the Recommendations component, we gather information about the current situation at an organization.  This includes everything from detailed practices, processes and tools, to strategies and organizational culture.  This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility.  The Assessment includes an online portion, an on-site portion and an off-site portion.  The assessment work naturally leads to the development of the playbook.

The online assessment requires that each person throughout an organization complete an online survey about corporate culture.  It includes three major sections: existing challenges, sense of urgency, and level of teamwork.  This cultural survey is the foundation of understanding how to be successful with Real Agility.  Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization.  This includes high-level information about the structure of the organization, client and vendor relationships, and staff.  Additional surveys may also be administered to understand other aspects of the organization.  For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.

The onsite portion of the assessment combines in-person interviews and workshops with staff and managers.  Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile.  The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof).  Typically we need a meeting room committed to our consultants for doing interviews.

The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results.  We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc.  We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results.  Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.

Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online.  We also have a number of proprietary tools.

The playbook maps out a path to a successful Real Agility transformation.  It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility.  The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams.  The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results.  Two critical questions that are answered in the Playbook include:

  • What Agile method or methods should we be using and why?
  • What organizational change approach should we take and why?

We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along.  The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.

Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Leveraging the Team for Good PDPs (if you need them)

I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team.  PDPs are still the deliverables of individuals required by the organization and likely will be for some time.  The organization is still in the early days of Agile adoption (pilots) and they are large.  So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.

The Plan:

  • Facilitate a team workshop to create an initial Skills Matrix;
  • work as a team to develop a PDP for each individual team member that directly supports the team’s high-performance Goal (already established)—
    • in other words, when considering an appropriate PDP per individual, the team will start with the team’s performance Goal and build the individual PDP from there;
  • develop a plan as a team for how the team will support each team member to fulfill his/her individual PDP—
    • in other words, all individual PDPs will be part of the team’s plan for team improvement;
  • Internally publish the plan (share with management).

I’ll follow up with another post to let everyone know how it goes.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Humor – A Typical Project Launch Meeting

One of the things that I love is how many great videos there are that show the ridiculousness of a lot of corporate behaviour.  This video is a hilarious (and painful) look at one aspect: the way we treat our experts.

Of course, I don’t mean to say that we should never be sceptical.  Rather, sometimes we just have acknowledge reality: there is no magic to make a red line with a green marker.  The role of the expert is to clarify reality to others through their knowledge and experience.

When I am doing CSM and CSPO training, I often am faced with people who want to know how to make high-performance teams with distributed team members.  They are often looking for some sort of magical solution.  This is an example of not being willing to face the reality that distance makes communication slower, less effective, and less likely to happen at all.

I’m sure all of you have interesting experiences of being the expert in something and your audience pushing you to find the magical solution… share your stories in the comments please!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Minor Update: Seven Essential Teamwork Skills

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Summer of Scrum Toronto 2014 Pre-Registration

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Inception: Facilitating Innovation Towards Valuable Results

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration

 


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Sometimes I Just Need to be Pedantic

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.

Finally:

Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Sprint Review Timing – Article by Mike Caspar

Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it.  From the article:

If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.

Please, for the sake of your team(s)….

When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!

Stakeholders are people too. They don’t want to let the team down either.

(Emphasis added.)

Mike has great experience working with Scrum teams and I hope you read through his other articles as well.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Scrum Team Assessment updates

The Scrum Team Assessment has been used by 36 teams so far including 15 teams in Asia.  The organizations that have used it are involved in many industries including high tech, mining, media, human resources, engineering, telecomm, and financial services.  We launched the official “Professional” version in January and have great success with teams using it to improve their Scrum and Agile practices.

Two interesting results to come out of the Scrum Team Assessment so far:

  • Most Scrum teams are scoring “B’s” and “A’s” on the Scrum rules
  • Organizations are doing a poor job of supporting their Scrum teams to encourage high-performance

Of course, this is still a pretty small sample size.  I’m looking forward to that growing significantly over the next few months.

The latest update of the Scrum Team Assessment includes the following changes:

  • More complete statistical data about how your team compares to other teams
  • Updated expert system rules (these will continue to evolve!)
  • New and updated recommendations
  • Numerous report formatting improvements for better clarity
  • Several minor bug-fixes

This is a minor revision to our “Professional” level tool.  We are still planning a big announcement for new “Basic” and “Advanced” pricing levels soon!  Stay tuned…


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Agility Program – Execution and Delivery Teams

Execution IconIn a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

See also the article on the Recommendations component of the Real Agility Program.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

“Meet: Scrum”, the Diagram

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.

ScrumDiagramTravisBirch

You can download it at this link: Meet: Scrum.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Great little presentation on Retrospectives… and a bonus download!

If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives.  I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago.  Very helpful with some practical information, some great links… I strongly recommend checking it out.  My only concern is that they limit the scope of retrospectives too much.  I have a list of topics that I think can and should be considered in a retrospective:

  • Technology / tools
  • Work space / physical environment
  • Corporate culture
  • Corporate standards and policies
  • Teamwork
  • Work planning and execution
  • Skill sets
  • Interpersonal dynamics
  • External groups
  • Personal circumstances and needs
  • The process you are using

 

This list comes from a presentation I used to include as part of my Certified ScrumMaster course.  (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.)  Here is a PDF version of the Retrospectives Module.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Back to the Basics: Coding and TDD

I’ve been working for the past year on building the Scrum Team Assessment (yes, you can still go get it for your team :-) ).  I’ve been doing all the work on it personally and it has been great fun.  The best part of it has been that I’m back into coding.  And, with that, of course I have had to take my own advice about Test-Driven Development and the other Agile Engineering Practices.  But it hasn’t been easy!

I’m using PHP for the web front end, and Python with OpenERP for the back end.  My testing tools include Selenium for Acceptance Testing and PHPUnit for unit testing.  And… nothing yet for the Python back-end.  This is still a sore point with me.  Normally, I would find the back end TDD process easier… but OpenERP has been a HORRIBLE BEAST to use as a development platform.  Well, I might exaggerate a bit on that, because it is really just the complete lack of well-written API documentation and sample code.  Which is funny, because there are tons of open-source extensions for OpenERP written.  Anyway, I don’t want to complain about it too much, because in many other ways it is a fantastic platform and I wouldn’t easily switch it for anything else at this point.

Back to testing.  Last week, a client using the Scrum Team Assessment found a bug… and it was one of those ones that I know made them consider not using the tool anymore. Fortunately, our contact there has the patience of a Redwood, and is helping us through the process of fixing the system.  How did the bug happen?

Because I didn’t do _enough_ TDD.  I skimped.  I took shortcuts.  I didn’t use it for every single line of code written.

<Failure Bow>

The question for me now, is “why”?  Fortunately, the answer is simple to find… but solving it is not as easy as I would like.  I didn’t follow my own advice because I was learning about too many things at the same time.  Here’s what I was learning all at once over a three week period in December when I was doing the real heads-down development work:

  1. PHP and PHPUnit
  2. Python
  3. OpenERP (APIs for persistence and business logic)
  4. RML (a report generation language)
  5. Amazon EC2, RDS and Route 53
  6. Some Ubuntu sys admin stuff
  7. VMWare Fusion and using VMs to create a dev environment
  8. Postgresql database migration
  9. Oh, and refreshing on Selenium

Like I said, FUN!  But, a bit overwhelming for someone who hasn’t done any significant development work since 2006-ish.  As well, because of learning about so many things, I also didn’t have a good setup for my development, testing and production environments.  Now I have to clean up.  Finally, I also forgot about another important Agile Engineering practice that is used when you have lots of intense learning: the Architectural Spike.

I have to make sure that I take all that I’ve learned and create a truly good dev and test environment (because that was a huge hinderance to my work with both Selenium and PHPUnit).  And I have to take the time to learn to do the testing in Python (I would love suggestions on a good unit test framework)… and go back over that code, even though most of it is simply declarative of data structures, and make sure it is well-covered by unit tests.  Ideally, I might even consider throwing some code away and starting from scratch.  One possibility I’ve considered is to get rid of PHP entirely and build the whole system with Python (I’d love some thoughts on that too!)

Why am I doing all this?  Well, I really think that the Scrum Team Assessment is an awesome tool for teams that maybe can’t afford a full-time coach.  It certainly isn’t a complete replacement, but I’ve poured my knowledge and experience into it in the hopes that it can help a bunch of people out there do Scrum better… and more importantly, create great teams that produce awesome business results and where people love to come to work every day.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail