Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

WARNING: Shameless plug for my session at Agile2014 ahead.

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

DocFormula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.

Posted in Agile Adoption, Agile Coaching, Agile Development, Agile Methodologies, Agile Teams | Leave a comment

With Me It’s All or Nuthin’

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.

 

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Agile Tools, Continuous Integration, Enterprise Agile, Extreme Programming, Iterative Development, Scrum Development, Scrum Methodology, Test Driven Development, Uncategorized | Leave a comment

Lots of carryover? Try swarming

swarming4Scrum teams are made up of individuals with cross functional skills that commit to completing the sprint backlog as a team. Instead of a traditional Project Manager assigning tasks, the team decides how they are going to get the work done and individuals choose or sign up for the work they want to do.

If on sprint planning day, the team determines the owner for every task, then it’s very easy for our introverted development teams to go heads down at their desk and only focus on their personal ‘to do’ list. Even though they are having a daily stand up, if they are not truly paying attention to how the team as a whole is tracking according to their plan, then teams can end their sprint with several backlog items partially completed. The team has to own up to the stakeholders during the sprint demo that they didn’t meet their commitment and that walk of shame is no fun. Plus, a backlog item that is 90% complete does not make the company money so the team discusses in the retrospective how to prevent that from happening again.

I would challenge a team who finds themselves in this situation to no longer determine the owner of tasks on sprint planning day. Instead, allow team members to sign up for a task daily throughout the sprint following the swarming approach. Like when worker bees swarm together to build a new hive, teams should swarm together to work down the prioritized sprint backlog. On the first day of the sprint, the team should put only the top backlog item in progress until it meets the definition of done. Once the top backlog item is done, then the next backlog item in the list can be put into progress. Based on the size and skill sets of the team, they may find that their WIP limit is two to make sure everyone has a task on the first day of the sprint. To help enforce this, the team can set a WIP limit of one or two on the ‘In Progress’ column of their story board. This focus will:

  • Keep the team working together closely and will result in less context switching
  • Keep the intensity level high on getting impediments resolved ASAP
  • Forces the team to test early in the sprint instead of it becoming a bottleneck at the end
  • Product Owner can provide feedback, verify and accept a backlog item early in the sprint instead of on the last day

The Product Owner who has three backlog items done and accepted feels a lot better than the Product Owner who only has seven items that are 90% complete.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Enterprise Agile, Kanban, Scrum Development, Scrum Methodology | 2 Comments

Agile Beyond Software: A Manifesto For All Industries

Lean ManufacturingWhen the Agile signatories created the Manifesto, software was obviously at the core of their thinking, which makes sense as they were all building software at the time.  As it has grown in its popularity, however, Agile has gone beyond software.  So, should the original Manifesto be adjusted to accommodate these new adopters?

There is an ongoing debate about whether Agile is only for software development or whether it can be applied to other industries.  In order to even attempt to see if Agile could be applied, we should first take a look at the original values and principles, which you can find here: http://www.agilemanifesto.org.

With that, here is a stab at what it might look like if it were to change. I’ve underlined any text that has been altered from the original:

Manifesto for Agile Product Development

We are uncovering better ways of developing
products by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

Here are the principles with changes:

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable products.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working products frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

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

Working product is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

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

Okay, so there it is.  Yep, it’s that simple, I just changed the word “software” to “product”. Maybe you think there could be issues with some of these values or the principles if they were applied to other-than-software production.  I’d like to hear your thoughts.  If you have other industry experience, would these be good to apply to your industry?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Marketing, Agile Methodologies, Agile Portfolio Management, Agile Project Management, Agile Teams, Distributed Agile, Enterprise Agile, Kanban, Lean, Scaling Agile, Scrum Development, Uncategorized | Leave a comment

New ScrumMaster Tips

Team

I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology | 1 Comment

What does it really mean to be an Agile Tester?

I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.

What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.

For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.

I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.

All for one

As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!

You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”

OK, allow me to elaborate…

For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.

It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.

It means that you embrace change; you collaborate well with your team members as well as those outside the team.

It means you know how to help other folks on the team automate tests and help drive exploratory testing.

It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.

It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.

It means you guide other folks on the team, helping them improve upon their testing knowledge.

It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.

It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.

It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.

It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.

It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.

It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.

It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.

It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.

It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.

In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.

It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.

It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.

And yes, it means you actually run tests too, whether they’re automated or manual.

Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.

If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Project Management, Agile Software, Agile Teams, Agile Testing, Continuous Integration, Distributed Agile, Enterprise Agile, Iterative Development, Scaling Agile, Scrum Development, Scrum Methodology | Leave a comment

Agile Beyond Software: GM Case Study

Car EngineThere is an ongoing debate about whether Agile is just for software or if it can be extended to other industries.  I for one believe the Agile values and principles can be applied beyond software, but, in a recent discussion about this, a colleague raised a concern that some of the principles would be difficult to apply for some industries.  The principle in question: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

The thought here is that manufacturing industries have a high cost for changing once production has begun. This is true, it can be costly to change since production has to be stopped, parts changed, processes reconfigured, delivery would likely be delayed and there is cost in correcting any issues in products already produced.  However, one cost that is often dismissed is the cost of not changing.

Let’s consider the recent case with GM and the ignition switch malfunction.  According to several reports GM has issued a recall on about 2.6 million vehicles to repare the faulty ignition switch.  For arguments sake, let’s just pretend that the cost of the part and the cost to have a post production mechanic replace it is the same as the original.  That means for every replacement, they are paying double the original cost.  Then there are the costs for the accidents caused by the malfunctions, and the biggest cost, the cost of lost lives.  How do you put a price on that?

So, I think we can safely surmise that GM would have spent less money had they replaced the part when they found the issue.  What we should consider next then, is whether they could have replaced it, even late in development.  According to the graphic in this NBC article (http://www.nbcnews.com/storyline/gm-recall/infographic-when-did-gm-know-it-had-ignition-switch-problem-n68611) provided by Ronnie Polidoro, GM first found out about the issue in 2001.  Apparently they also dismissed a partial fix in 2005.  Now it’s 2014 and they have finally issued a recall.

It seems clear to me that, in this situation, accepting the change in requirements would have been easier and less costly than going with the chosen path.  It certainly seems that it would have at least been in the customer’s best interest to do so.

What are your thoughts?  Do you think Agile principles could be applied here?  How about Agile beyond software?  I look forward to your comments.

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Enterprise Agile, Lean, Scaling Agile, Uncategorized | Leave a comment

So you’re going to be a ScrumMaster?

Team“Well I am a PM now but they are making me a Scrum Master.” I have heard that statement countless times. Some PMs are happy about the new challenge, some aren’t and some just want to keep making those Benjamins. I have to admit even though being an embedded software engineer by trade the ScrumMaster role is my favorite role on a Scrum team. When asked what is a ScrumMaster I always respond with a servant leader and Agile champion for your team. Yes there are more details but I think simple is the best approach sometimes.

I thought it might be a nice time to talk about some of the qualities that a great PM has and how those look in an Agile environment. PMs tend to get a bad wrap from the Agile world so lets clear the air. I just so happen to have a fiancee that is a PM for a large company. She tries to give me a gantt chart for the week and I hand her story cards daily at breakfast. I asked her to take a survey of her peers which consisted of development, product management and other PMs. They came up with five qualities a PM has, here they are in no particular order.

Issue / Risk Assessment
Issue Resolution
Listening Skills
Manage Expectations of the Business
Process Oriented
On the topic of issue/risk assessment I can help your stress level by letting you know that issue assessment and risk assessment take different routes. Issue assessment gets the chance to happen everyday in team’s standup meeting. Of course if this is urgent it may be brought to your attention sooner. Risk assessment is happening all the time by way of the entire team. Is the sprint going to be completed, what stories might be slipping and what can we do as a team to deal with that.

Issue resolution is a key quality that will carry over. As a ScrumMaster you should do everything in your power to resolve issues or impediments for the team. This not only keeps the team adding value all the time it also builds their trust in you as the ScrumMaster. Issue resolution also requires a good listening skill.

Listening is a skill or quality that I think everyone is challenged with in life. Listening before you speak, listening before you start to think of your response etc. ScrumMasters have to fine tune this skill, even when it makes things uncomfortable at times. Some ScrumMasters tried to lead the team too often with words. I am a fan of posing the question and then letting the silence get uncomfortable enough that someone from the team answers. Which breaks the ice and conversation begins to flow. This also starts the baby step path to the team becoming more and more self organized.

Our next quality, managing expectations of the business, which is easier now! You get to manage it two weeks at a time or however long your sprints are. You will work with product owner to sprint plan and release plan if you are making use of that planning method. Better yet, let’s remove manage and add rank. Ranking is what a product owner is doing with the pieces of the value the business is looking for. Your job as a ScrumMaster may be to help the product owner provide details necessary to get the conversation and collaboration going! Those specs are you are used are gone and I challenge you to ensure the story doesn’t turn into a spec.

Being process oriented is good thing since you have new processes to learn. Scrum as a concept isn’t hard to understand but mastering it can take quite some time. That being said a Scrum team can take a year or more to fully mature. A good ScrumMaster is more than a certification, not to knock them. You will have times when you have to figure out the best way to passively guide the team towards better Agile values. You have to truly believe that what you are saying has value and can be successful.

So I go back to my definition, a servant leader and Agile champion. Live everyday for those around you and remember the values that Agile stands for. Go have fun with the rest of the pigs! (Search for it) I’m sure I didn’t paint rainbows and unicorns for the PMs out there reading this. I can assure you the ScrumMaster role will be one of the most challenging and enjoyable roles you’ve ever played on a team.

Posted in Agile Adoption, Agile Coaching, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 10 Comments

Why Agile Governance Matters at the Project, Program and Portfolio Levels

Guest post by Monte Montoya, cPrime

For any organization attempting to migrate to – or sustain – agile processes, governance is an important consideration. This is especially true as companies grow. While small companies can likely get away with fairly informal governance, larger enterprises cannot function effectively without formal controls in place.

As we touched on recently in the article “How to Develop Your Own Recipe for Agile Governance,” every organization can benefit from developing its own unique “recipes” for agile governance that fit the organization’s specific needs and projects.

But why does governance matter so much? Let’s break the answer down into three categories: the Project, Program and Portfolio levels.

Agile Governance at the PROJECT LEVEL

To keep our terminology clear, we’re considering a project to be “a temporary endeavor undertaken to complete a unique product, service, or result.”

Effective governance at the project level identifies and advocates for specific goals to be reached during each sprint or iteration. It helps determine the core requirements that comprise the initial release of the project and the criteria by which additional goals will be decided upon.

Since multiple projects may be closely interrelated, effective Agile governance is often achieved at the program level where these multiple projects interface with broader business objectives.

Agile Governance at the PROGRAM LEVEL

A program can be defined as “multiple related projects that are managed in a coordinated fashion.”

At the program level, the more comprehensive strategic goals of the organization filter down to individual projects that produce tangible results. Therefore, this is the optimal location for Agile governance to stem from.

Managers at the program level are in a key position to fully understand the requirements of each individual project without being directly responsible for negotiating the details. They are also in a position to understand and translate the overarching strategic goals of the organization to project managers who may otherwise suffer from tunnel vision.

Agile governance also provides managers at the program level the means to monitor and report on the progress of projects under their oversight.

Agile Governance at the PORTFOLIO LEVEL

A portfolio is a collection of programs or projects and other work grouped together to facilitate effective management in order to meet strategic business objectives.”

Managers working at the portfolio level are primarily concerned with organizational strategic goals and may have limited knowledge or understanding of individual project successes or failures. However, they do need to know the general direction in which the company’s projects and programs are headed, and they will concern themselves with business continuity matters such as budget and time line more so than those in project teams.

As utilized by the program level, effective Agile governance allows for clear and measurable monitoring of individual projects and broader programs in a language portfolio managers can understand and work with: time, money, and personnel.

Help For Those with RAGE Issues

Establishing effective Agile governance is a potentially complex and difficult process.

For help in making it happen for your organization, take a moment to review our Recipes for Agile Governance in the Enterprise services.

Learn more about RAGE at the Project, Program and Portfolio levels by checking out our RAGE Introduction Webinar:

Posted in Agile Adoption, Agile Portfolio Management, Enterprise Agile, Scaling Agile | Leave a comment

It Isn’t Agile; It Is Life!

One of the things I like to start with when introducing agile development is the quick application of agile development to life. I ask the question: “Did you plan today six months ago? Did you plan getting out of bed, then taking a shower, then brushing your teeth and then making your lunch, etc.? No, well that’s interesting because I didn’t either.”

However, my mind being an agile machine already figured out my morning in the order that is natural for me. You complete your morning in an order that is natural to you. That’s what the team is trying to do in an agile development environment – add value in an order that makes sense to the user.

My next question, “In life, did you have goals?” Sure you did. You wanted that degree, you wanted a fiancee, a family. Just like Epics are large features or initiatives for products, your life has some large features and initiatives, also!

Now my expansion on that approach…  Bruce Feiler (@BruceFeiler) helped me take that to the next level with his Ted Talk titled “Agile Programming for Your Family.”  I was currently blending a new family: myself with two children and my fiancee with two children (Ages 4, 7, 9, 12).  I decided to put this “stuff” I preach to the test.

I went to the local office supply store and for about $50 I was able to produce four boards for the kids’ rooms.  Keep in mind, I have zero craft skill.  For my four-year-old I used a picture-based board which she could understand, and more elaborate solutions for the older children.  Two examples are below:

Ireland's Board

Austin's Board

With this layout, it is so easy even a four-year-old can do it! If my youngest needs to make her bed, I move the magnet to the frowny-faced girl.  When she is done, she puts the magnet under her picture and if either of us approves, we will move it to our picture. If we do not approve, we explain why and move the magnet back to the frowny-faced girl. Now if I walk into a bedroom and their bed is not made, or their floor is dirty, I simply move the magnet to Not Done.  After a short time I get, “Can you come check my board?” from one of the children.

While we do not do daily standups, we have weekly retrospectives where we all sit on the floor and talk about the week.  What went bad, went well, and what could we improve on?  This is also a great time to congratulate someone or provide a family announcement since we have the children half-time.  The children also get a chance to have a voice and we have a positive environment for change.  The adoption of this approach has made a huge impact on our family.  The older children self-organize (a.k.a., tell on each other) if one of them is slacking; the younger children actually encourage each other and often help each other complete their tasks.  We were finally asked about allowance…

While we don’t like that word – and also like to instill life lessons – we did implement a flat salary that has additional commission benefits. If the children keep their boards up all week without too much parental encouragement, then they receive their salary.  If they go above and beyond the board, they receive a commission.  For example, maybe my nine-year-old vacuums the upstairs without this being a task.  He just realizes it needs to be done and does it.  We make a mental note of that.  Now this is where it gets interesting. During the retrospective we hand out the cash, in all Ones, of course.  We pass it out around the circle. If someone didn’t go above and beyond, they get to hold that extra money as they pass it around the circle until it gets to the rightful owner.  Are we driving behavior? You bet we are!  Positive behavior that if you want something in life, go get it!

While the salary and commission do not have that much to do with agile development, the approach provides us with a mechanism for other teachings which we would like our children to pick up.  So I have Bruce to thank for the success we have had. If you haven’t had a chance to see his talk, I have provided a link below.  I truly believe that agile development is a successful philosophy which any company or family can adopt and be successful!

Agile programming for your family – Bruce Feiler

 

 

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Methodologies | 2 Comments