If you are someone who is passionate about agile, the word “Waterfall” is usually used in a derogatory manner or, at least, when you use it — you are making the stink eye. On the converse, if you are someone who practices what is popularly known as “Waterfall” Project Management, you generally get offended or defensive when the word “Waterfall” is used.

Here’s how the conversation plays out:

Agile practitioner:  ”There’s no way I’ll ever work on a Waterfall project.”

Waterfall practitioner: “There’s no way I’ll ever work on that Agile project.”

Agile practitioner: “Waterfall projects are never successful and I hate being told what to do.”

Waterfall practitioner: “Well at least we do work and don’t practice that Agile witchcraft and all that kumbaya mumbo-jumbo.”

Agile practitioner: “Well, your mama said Waterfall is for losers.”

Waterfall practitioner: “Don’t be talking about my mama!” …

[Chaos ensues]

 

The sad part about this dialog is that although it’s somewhat fictitious, I’ve heard similar arguments at organizations and with colleagues who work across all spectra of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — is that no one is really clear who started calling it Waterfall. It’s obvious that when diagramming out a sequential process, it looks like a waterfall:

Often, people credit Dr. Winston Royce with Waterfall project management, especially with respect to software engineering when, in 1970, he wrote a part in a white paper that describes this approach (read it here). The funny thing is that he goes on in that same white paper that is credited for starting the Waterfall practices to describe how risky it is, and that, in order to mitigate the risks, each stage of the Waterfall process should do things iteratively and incrementally.

Waterfall project management is really Sequential Project Management. Meaning we perform a sequence of activities and there are generally stages, maybe with sign-offs, and usually hand-offs, to another group of people who are charged with performing the next sequence and consuming the output of the previous sequence. Some refer to this as Traditional Project Management, but in most environments its called Waterfall.

I’m not going to discuss the differences between the two and which approach I think is better — it should be clear since you are reading an agile blog. I will say that I think that the merits of each approach are obvious and each approach has challenges. The usage of one approach over the other really depends on the project and possibly the people engaged.

What I am going to say is that, in the world in which we all live today, it is very likely that we’ll have a mix of projects using a more of an agile approach and one using more of a Sequential approach. Sometimes we’ll have to join forces and combine the output of these approaches into one. Of course, we are learning and adapting ways to do this, but that too is another discussion altogether.

Let’s face it, when words start dividing people, we probably shouldn’t use them any more. Instead call the project management approaches what they are – iterative and incremental, or sequential, or continuous, or simply ad hoc. Also, be aware that the moniker we place on people isn’t really on the people; it’s on the processes by which they may operate in — and they may be really comfortable in that process. Generally, they’ve put in a lot of blood and sweat to make it work. Sometimes we need to put the monikers aside and focus on “individuals and interactions over process and tools” (crazy how I got the Agile Manifesto into this blog, isn’t it?).

For now on, be aware and call it Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”

While at a recent Project Management Institute (PMI) event, the question came up of whether you could use agile techniques in Construction Project Management (after all, not all PMI members are IT Project Managers). Earlier in my career I worked for some electrical contractors, and thus have some first-hand experience in the Construction industry.

My first inclination was that agile would not be a good fit; but after doing some research, it turns out there are some examples of the application of agile and Lean principles to Construction (see also sources below). After all, software development is often contrasted with construction.

In general, agile is more applicable to the execution portion of a construction project, as there still has to be some fairly serious upfront planning. Major changes late in a construction project are generally hard to do efficiently. Also, the key principle of incremental delivery of value in the form of working software does not translate well to construction.  However, agile concepts such as customer collaboration and responsiveness to change have a place in a construction project. Lean methods applied to construction are beneficial in regards to creating material and information flows, maximizing value generation, and the use of plan-execute-and-control paradigms.

Once the overall design and master schedule for the project has been created, then a method known as the Last Planner System can take that master schedule and provide a process for breaking work down into smaller units that can be executed more iteratively:

 

Source:  Agile and Lean Applied to Construction

At a more tactical level, here is one way that typical Agile terms could be translated for use in Construction:

Source:  Agile and Lean Applied to Construction

In his post, “An Agile Construction Project,” Chris Klein has some ideas on how agile roles would be represented on a construction site. For instance, the Superintendent could be the ScrumMaster, as s/he would be responsible for running the various meetings and coordinating work on the site. The Project Engineer or Project Manager could fulfill the Product Owner role, as s/he would be responsible for maintaining various project artifacts, make decisions on various questions around interpreting design specifications, and could represent other stakeholders to the project team similar to a Scrum Product Owner or Product Manager.

Chris also talks about how the various meetings and ceremonies of agile and Scrum might look in a construction setting. The Daily Standup would be more of a Daily Status Meeting where the various trades would coordinate their efforts and the Superintendent coordinates to remove impediments. Once an iteration cadence is established (how Sprints would work in a construction setting would vary project to project) there could be planning meetings and reviews associated with those iterations that would support collaboratively planning and reviewing work found in agile. There could even be sessions to review the processes being followed on the job site that would look much like a Sprint Retrospective. After all, both agile and Lean are all about continuous improvement, and Agile Construction Management would want to reap the benefits of this practice as well.

This is still an emerging concept in application of agile methodologies, but may have more relevance as the prospect of large infrastructure projects such as an expansion of broadband Internet and the creation of a Smart Electrical Grid could stretch the capabilities for existing construction project management methods.

Below is a list of the key references that I used in putting together this post. These provide a good starting point if you would like to learn more about Agile Construction Management. There will also be a post in the VersionOne Product Blog that will give an example of how these concepts might be implemented in VersionOne.

Thanks for reading; please share with us your comments and questions below.

References:

An Agile Construction Project by Chris Klein:   http://chrisklein.wordpress.com/2009/11/02/an-agile-construction-project/

Agile and Lean Applied to Construction by Adrian Smith: http://ennova.com.au/blog/2011/09/agile-lean-compared-applied-construction

Agile Construction Projects by Brian Doll: http://emphaticsolutions.com/2011/04/23/agile-construction-projects.html

Lean Agile in Construction Projects – 9/11/11 – 10 Years Later (Agilescout): http://agilescout.com/lean-agile-in-construction-projects-91111-10-years-later

1. The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale.  It is illustrated in the big picture.

As Scrum is to the Agile team, SAFe is to the Agile enterprise.

2. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale.  It is field-tested and enterprise-friendly.
3. SAFe is the brainchild of Dean Leffingwell.

As Ken Schwaber and Jeff Sutherland are to Scrum,
Dean Leffingwell is to SAFe.

4. SAFe is based on Lean and Agile principles.
5. There are three levels in SAFe:
   * Team
   * Program
   * Portfolio

At the Team Level:

6. Scrum with XP engineering practices are used.
7. Design/Build/Test (DBT) teams deliver working, fully tested software every two weeks.  There are five to nine members of each team.
8. Rally’s weekly TeamStart webinar series covers the basic practices at the team level.

At the Program Level:

9. SAFe defines an Agile Release Train (ART).  As iteration is to team, train is to program.
10. The ART (or train) is the primary vehicle for value delivery at the program level.  It delivers a value stream for the organization.
11. SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
12. Between 5 and 10 teams work together on a train.  They synchronize their release boundaries and their iteration boundaries.
13. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI).  A demo and inspect and adapt sessions are held.  Planning begins for the next PSI.
14. PSIs provide a steady cadence for the development cycle.  They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
15. New program level roles are defined
    * System Team
    * Product Manager
    * System Architect
    * Release Train Engineer (RTE)
    * UX and Shared Resources (e.g., security, DBA)
    * Release Management Team
16. In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles.  If they have deep domain expertise, they are likely to fill the Product Manager role.  If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
17. SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.  Rally provides regular public and private Leading SAFe certification classes.
18. SAFe makes a distinction between content (what the system does) and design (how the system does it).  There is separate “authority” for content and design.
19. The Product Manager (Program Manager) has content authority at the program level.  She defines and prioritizes the program backlog.
20. SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The program backlog is a prioritized list of features.  Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features decompose to User Stories which flow to Team-level backlogs.
21. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.
22. The System Architect has design authority at the program level.  He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met.  He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.
23. The UX Designer(s) provides UI design, UX guidelines and design elements for the teams.  In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.
24. The Release Train Engineer (RTE) is the Uber-ScrumMaster.
25. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.
26. Rally’s monthly Program webinar series provides an overview of Scaling Agile Programs with SAFe.

At the Portfolio Level:

27. PPM has a central role in Strategy, Investment Funding, Program Management and Governance.
28. Investment Themes drive budget allocations.
29. Themes are done as part of the budgeting process with a lifespan of 6-12 months.
30. Portfolio philosophy is centralized strategy with local execution.
31. Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes.
32. There are business epics (customer-facing) and architectural epics (technology solutions).
33. Business and architectural epics are managed in parallel Kanban systems.
34. Objective metrics support IT governance and continuous improvement.
35. Enterprise architecture is a first class citizen.  The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.
36. SAFe patterns provide a transformation roadmap.

  Legacy Approach Lean-Agile Pattern

#1

Centralized control

Decentralized decision-making

#2

Project overload

Continuous value flow

#3

Detailed project plans

Lightweight business cases

#4

Centralized annual planning

Decentralized, rolling wave planning

#5

Work breakdown structures

Agile estimating and planning

#6

Project-based funding

Agile Release Trains

#7

Projects and PMBOK

Self-managing teams and programs

#8

Waterfall milestones

Objective, fact-based measures and milestones.

Table above reproduced with permission of Leffingwell LLC and Scaled Agile Inc

37. Rally’s monthly Portfolio webinar series provides guidance on Lean | Agile approaches to PPM.

Adoption

38. Adoption focuses on identifying a value stream.  A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers.  Value streams are realized via an Agile Release Train (ART).
39. SAFe poses questions to help identify value streams (ARTs):
    * What program might adopt the new process the fastest?
    * Which executives are ready for a transition?
    * What are the geographical locations and how are the team members distributed?
    * What programs are the most challenged, or represent the biggest opportunities?
40. When you identify a value stream, you go “All In” and “All at Once” for that train.
41. Rally is an SAI Gold Partner.  Rally’s cloud-based solutions for managing the Agile development lifecycle directly support SAFe.  Read two independent analyst reports that show why “Rally Software continues its leadership in Agile/Lean.[1]”

[1] The Forrester Wave™: Application Life-Cycle Management, Q4 2012

.content td { padding: 2px 6px; } ol li { margin-bottom: 13px !important; } .safe-table th { background: #444444; font-size: 13px; color: #fff; border: 0; padding: 8px 0 0 8px; } .safe-table td { padding: 11px; background: #f4f4f4; border-top: 3px solid #fff; border-left: 3px solid #fff; } .safe-table td.first_col { border: 3px solid #fff; } .safe-table td { font-size: 13px; color: #444; margin-bottom: 8px } .safe-table td p { margin-bottom: 3px; } Rob Pinna

Countdown: 17 days until RallyON!  As we get closer to the event, we are knee-deep in content (and planning a welcome reception that will knock your socks off). We're refining the sessions and how they map to our overall themes of people, practice, and technology. This year's conference adds a new focus on Rally's platform, and how to optimize up and across the organization.

People - What makes an Agile leader different? What kinds of trade-offs are involved in their decision-making? Find out as Rally's Tim Miller and Christopher Avery explore what it means to consciously lead an Agile organization.  Also find out Jean Tabaka's "secret sauce" that Agile heroes use to keep their world in peace and deliver at scale.

Practice - One of our customers is presenting "Beyond Swarm Soccer," and the name says it all. Are we all chasing the ball, or do we work in concert across the field? Also, as Agile practitioners, how do you know when you're getting better? Applying extensive research, we've identified the Seven Deadly Sins of Agile Measurement, and will discuss which metrics matter.

Technology - We're taking a technical deep-dive this year by sharing lessons learned from both our customers and our own use. Sessions include product development using a build-measure-learn process, creating the most useful and used dashboards, and managing complex QA and test automation.  Our own engineers take center stage to discuss Rally's approach to building Lean product experiments and how we apply that to our product roadmaps.

There are too many great sessions to choose from, so bring a colleague -- or seven -- to share the learning.  We’ll see you next month in Boulder.  

Rally Software

Since Rally launched Rally Portfolio Manager in Dec 2011, I have worked with many PMOs, program managers and portfolio managers who ask: How can I adopt Rally’s portfolio management solution when I already have a PPM tool?

The answer: Use a Rally--PPM tool integration.  But what does this look like, and what does it provide?

Integrations ensure your PPM dashboards keep their value.

As Gartner stated at their PPM and IT Governance Summit last year, there is not a “ one size fits all” solution in the portfolio management world right now. That world is experiencing a major disruption and until it settles, which likely will take years, PPM providers have to play well with one another for the sake of providing you with comprehensive solutions that provide real value.

Here is one example. Agile continues to grow as a standard for project management. So portfolio dashboards must include Agile projects as well as traditional waterfall projects or risk losing their value. An integration with Rally would make sense here.

Which PPM vendors have partnered with Rally?

In 2011, several PPM vendors (Daptiv, Planisware, Oracle) partnered with Rally to offer an integration to Rally’s Agile solution. With the launch of Rally Portfolio Manager in late 2011, more integration possibilities arose. In 2012 Innotas created a bidirectional integration, Pervasive Software (now Actian Corporation) wrote the CA Clarity integration, and Rally’s own services group built an integration to HP PPM. The latest PPM integration was co-designed with Planview for several joint customers.

The benefits of integration are extensive.

The integration with Planview Enterprise is currently the most extensive bidirectional third-party integration to date between Rally and a PPM solution. Planview leveraged several new aspects of our free API to provide these key benefits:

1. Synchronization. The Planview integration automatically creates a matching Program/Initiative in Rally Portfolio Manager when you create portfolio initiatives or programs in Planview
2. Delivery of Valuable Increments. Focus on delivering valuable increments for the Program/Initiative (instead of focusing on being ‘on time and on budget’) by creating Features below the Program/Initiative in Rally Portfolio Manager
3. Real-time Status. As Agile teams work on implementing the Program/Initiative, portfolio managers & PMOs automatically view the progress of those Programs/Initiatives in the Planview portfolio dashboards, including the percent of work done based on actual Agile execution facts. Red-green-yellow status indicators are based on actual Agile execution,  actual start and end dates... you get the idea :).
4. More accurate cost data. If your organization is required to track software capitalization using a PPM tool, the integration synchronizes Rally’s timesheets with Planview’s timesheets so that everyone can stay productive in their own tool and avoid context-switching. The result? Your cost data is more accurate than when developers enter their time weekly or bi-weekly in a separate PPM tool.

If your organization currently uses mixed development methodologies (Agile, waterfall, iterative), then PPM / Rally integrations provide a way to adopt Agile at your pace while retaining your current portfolio dashboards. Now you can include your Agile programs in those dashboards.

See the integrations in action

Customers will present their use of the Planview and CA Clarity integrations at our RallyON user conference in June. If you are attending Gartner PPM shows late this month in the US or early next month in the UK, come on by our booth to see live demos!

Catherine Connor

Do you want to have more effective daily stand-ups? Do you want to have the planning meetings flow better and increase the value of these meetings? Do you want to see continuous improvement flow from your retrospectives? If your answer is yes, then put it on the Team.

I’ve written about trust, relying on strengths, and improving self-organization many times — and the message of these can be summed up as “Putting it on the Team.”  Make the team responsible for solving problems; make the team responsible for defining how to deliver; and making the team accountable for delivery.

Most of the times when we talk about the concept of the team self-organizing, is it more focused on the “how” part of delivery, and not the process. However, remember that the meetings (or ceremonies as some call them) are primarily for the team. Specifically, the Iteration Planning, Daily Stand-up (or Daily Scrum), and the Retrospective meetings — these are for the team, not the stakeholders or managers. Do the stakeholders and managers gain value from these meetings? Yes, but the real value is the fact that the team takes ownership of what they are going to deliver; they take ownership of holding each other accountable to deliver and work through problems themselves; and they take on the responsibility of improvement.

A lot of times we (as in Managers, Scrum Masters, Team Leads, Type-A Team Members) want to install processes and templates around these meetings. This usually happens after a few weeks or several months of trying an agile development framework and either not following the guidelines of the framework or the team not taking the initiative to make improvements. We’re not getting any value and the team is resisting and or blaming the whole concept — we want to fall back to more structure and being told what to do.

A great example of this is when a team’s stand-ups start becoming mundane, overrun their time boxes, and team members don’t show up. So what happens is we come up with a template for the team to keep up with for daily stand-ups, as well as establish a set of metrics we answer to during the stand-up. And of course, this just becomes one more thing for a team member to keep track of, as well as an unintentional mechanism of command-and-control.

As an ex-Director/Manager, I often wanted to step in and help — and I usually would come up with a template and/or some hard-prescribed structure and tell the team to follow it. I wanted to help, and that’s what Managers genuinely want to do. But I was quickly put in my place when one of my team members said, “Let us figure it out; it’s our problem.” I gave guidance and advice, but otherwise I got out of the way. I let the team come up with how they were going to make their meetings more effective. And at the end of the day, they simply looked at the frameworks themselves and decided to more closely follow the existing framework guidelines — e.g., keep stand-ups to 15 minutes and stick to the script, then allow the time remaining to become open-space troubleshooting time.

At the end of the day, remember that more process does not equal more better. Rely on the team to solve problems, over-instituting process and templates to solve problems. I think I’ve heard this before somewhere …

I love riding 100 mph on twisty, turning race tracks -- my favorite is Laguna Seca in Monterey, California. In racing, as in business, keeping the finish line in mind is important, but if you can’t negotiate the curves and respond quickly to changing conditions along the way -- you won’t win.

In this uber-competitive technology marketplace, the pace of change is only increasing. Disruptive new technologies are changing the game. Savvy business leaders are applying key agile concepts of continuous innovation, shorter iterations, and fail early/fail fast/fail often experiments not only to the development team - but to the entire portfolio management process.

Agile is not just for developers anymore. Once considered an esoteric “thing” that software developers “did,” Agile practices have moved mainstream and are spreading across the the enterprise. Business leaders are working to engage more people throughout the entire company to make more informed decisions at a faster pace.  The demand for better business agility is especially evident for portfolio management and strategic planning that has traditionally been tied to annual planning cycles.

An Agile business will establish a much faster cadence than the traditional annual planning cycle.  It doesn’t start and stop each quarter or once per year.  Planning and preparation become a continuous flow process with a regular cadence of weekly, monthly, and quarterly events for planning, execution, and strategic decision making.

No Time to Wait: Embrace the MVP

Betting on a big-bang project to deliver new software in a 12-to-24 month development cycle is a potential recipe for failure given the current pace of change.  Even if you are trying to plan a six-month product cycle, you may miss the latest handsets and the latest tablets - in other words, you are going to be behind.

An Agile business focuses on delivering incremental value in shorter time frames.  This means each increment has to be smaller and hyper-focused on the value to the business or customer. Desired capabilities need to be reduced to Minimal Viable Features that are validated for the scenarios people want and use.  By delivering functional software sooner, you have more opportunities to get customer feedback, adjust and adapt.

In some scenarios, evidence will suggest making small adjustments - other times a major pivot may be called for. Instead of betting the whole pot up front (as in waterfall), break opportunities into incremental objectives that can be validated along the way. By embracing the concept of a Minimum Viable Product, you can get to market quickly, then refine and expand.

Visibility and feedback are critical for steering effectively and making smart decisions.  Kanban boards help people collaborate by making it easy to see the stage of planning or development key projects are in.  Simply getting executives involved to see how much work is “in flight” on a Kanban board often brings an “ah ha” about what really matters to the business. Then, everyone can agree on working on the most important things first.

Don’t Be Left Behind

A new wave of Agile transformation is changing the way businesses fund and develop projects. Business must learn to embrace agility as more than a development approach if they are to survive. Strategic planning, product and portfolio management are now recognizing that Agile offers the best chance to keep pace and win the race. Agile is becoming a necessity for businesses trying to keep current in this changing marketplace.

To learn more about how to build an Agile business, sign up for Rally’s conference, RallyON June 3-5, 2013 and attend my session on Monster Portfolios.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Bruce Winegarden

You may have a well-articulated, strategic roadmap BUT how, when and what value you deliver against that roadmap can fluctuate. A benefit of iterative delivery and deliberate learning cycles is that product teams can tweak or radically change output based on what is discovered. Build, measure, learn and change.

A high-performing product team will stop working on ideas when there is evidence that the value is not as high as projected, and start testing new ideas. Embracing this agility means recognizing change early and adjusting often. Any predictions you made one sprint ago should be questioned. Roadmaps created one quarter ago should be questioned. So how can we get better at encouraging and responding to change vs. the extreme: adhering to a fixed, top-down plan?

• Ensure visibility into product team initiatives, and that they roll up to strategic initiatives and roadmaps – as a tool to continuously align the organization from strategic initiative to team focus and back up the chain.
• Build flexible roadmaps that are outcome-driven while promoting change and innovation.
• Plan continuously at all levels in the organization, align, re-plan and align again. Quarterly planning may be too late to be effective.
• Consider roadmap changes regularly. Don’t miss an opportunity to pivot early.
• Recognize that a forecast may only be relevant for a moment in time, based only on today’s assumptions. Review, communicate and adjust often. Or don’t forecast.

Hopefully your organization has this problem, where your teams are learning and delivering value beyond what was planned for, despite being less predictable about it. If not, it may be that your organization has a fairly static plan based on what the teams can deliver, based on the current constraints.

Organizations like these that “go agile” recognize that stable teams and iterative delivery can produce output more predictably… perhaps stabilizing roadmaps. But, competitive value comes when we are able to respond to what we learn, change direction, and produce valuable differentiators which we could not have predicted. While these outcomes are less predictable, agile enterprise-level planning needs to be just as dynamic as the product teams in order to organizationally align and deliver against what is measured and learned.

One of my team's daily standups (or maybe a standaround; not sure). That's me in the middle. Since then we've added a few more ladies to the team!

StandUp is a cornerstone of any agile practice.  It runs like a well-oiled machine at most agile shops. You get the talking stick (or ball, or the coolest piece of swag from your last agile conference (for the record, it was the V1 ‘Do Me Daily’ t-shirt), and you quickly and very professionally (even though you’re wearing cutoffs and flip flops) speed-speak your status so you can get back to your console and start slinging code asap:

“Yesterday I made the changes to the Uber-Widget that Bob asked for, and today I’ll be working with Matthew to get that styled up and looking good.  I may run into an impediment if Matthew isn’t available. When that’s complete, I’ll be ready to plan the next story.”

Then you pass the talking stick to the next team member like you’re shooting a 3-pointer (cuz you’re cool like that and it’s NBA playoffs time).  And so it goes around the circle until the ScrumMaster gets the stick in his hot little hands and tells everyone Matthew is out sick so let’s hold off on the Uber-Widget styling and jump right into the next story.

That’s how it’s supposed to work, right?  Tell the team what you’ve done, what you’re currently working on, and any impediments you’re facing.  The ScrumMaster then leads a discussion to resolve any impediments so that the team can maintain forward progress.

And it does work!  That’s the beauty of it – excellence only comes with practice, and we get to practice standup every day.  E-V-E-R-Y damn day.  So we’re pretty damn good at it.

However, even the most rigid training schedule needs a shake-up now and then.  Here at VersionOne, we have the occasional StandAround instead of a StandUp.  StandAround usually happens on a gray, rainy day when half the team is out sick.  You know it’s going to be a StandAround when the scheduled StandUp music gets through an entire song before the team manages to mosey over to the meeting area.  Once everyone is together, blowing on their fresh coffee, idle chatter bubbles up here and there.  Instead of the git-r-done vibe of StandUp, StandAround has a laid-back, get-to-know-’ya cachet.  Team members catch up, crack a few jokes, and then get on with their day.

Keeping the team healthy is just as important as forward progress.  So every now and then, have a StandAround.  Let it happen.  It’s OK!

 

How do you prioritize your features?  Is it a gut-feel kind of thing?  Is it based on who’s yelling the loudest?  Is it based on what drives your next big sale?  Do you do it collaboratively or alone?

In his book Principles of Product Development Flow, Don Reinertsen suggests using calculated economic models to decide what work to do first.  Specifically, he advocates an approach called Weighted Shortest-Job-First, or WSJF.  All other things being equal, the shortest job will deliver value soonest, so you should do that one first.  

But all other things are not equal - some projects reduce risk more than others, some enable other opportunities, and some are more important to your customers.   So you weight the scores - roughly, value over job size.

This approach is gaining popularity in part because the SAFe framework suggests you use it.  And it sounds great on paper.  But how does it work in the real world?

At Rally, we recently held a roadmap planning meeting with one of our product lines, and we tried a collaborative game to incorporate this economic technique into our planning session.  

We started by estimating relative job size.  Our group of 14 tech leads, product owners, and other leaders started with a bunch of stickies on a whiteboard representing value we wanted to deliver.   I asked the team to sort them by size - smallest items at the top of the board; largest at the top.  As they moved the items, they discussed each move.  People took turns, and asked clarifying questions.  

“Why do you think that one is so huge?” asked Greg, a product marketing director.  

“Because I have no idea what it means! It could be anything!” replied Ryan, a dev manager.   Together, they were able to clarify some details and get it sized, and we processed about 40 items in about 20 minutes.

As the movements slowed down, I stepped in and forced the stickies into 5 clusters.  I asked the team to correct my clustering if I had made mistakes, and they adjusted a few stickies.

We then translated them into rough cost.

I then asked the group about the smallest cluster.   “Do we think each one of these on its own could be completed by a team in significantly less than 3 months?”.  They said yes.  “How about the next group? Is that still less than 3 months?”  Yes.  “How about this next group?  Is it about 3 months, or is it more?”.  I did some simple math to figure a rough loaded cost for a team for a month, and used that to put rough dollar amounts on each size - $100k, $150k, $250k, $750, $1M+.

A couple of things about this:

1. You don’t have to be very accurate about this.  You just need a rough sense of relative size.
2. The dollar cost went up steeply for the larger items.  I wanted a dollar amount on the bigger items that would prompt fear, and then conversation about how it could be broken down.  Beyond 3 months, you have no idea how big these items really are.  But, if they’re valuable, you can break them down more.

Value Scoring

Once we had our jobs roughly sized, we used a Google spreadsheet to value score them.  To strictly follow Reinertsen’s approach, you’d actually calculate relative scores for user value, time value, and risk/reduction opportunity enablement value for each item.  But I had 14 people in the room and I figured across the group I could get similar results a quicker way.

I went with Johanna Rothman’s suggestion to let people distribute value points across all the items any way they wanted, and then explain their rationale.  

Here’s how it looked:

It’s not a ‘buy-a-feature’ activity.  Rather, each person got 10,000 points (enough to feel rich) to distribute however they wanted across all the items.  After 5 minutes, each person talked through their rationale.

This was the important part.

If Tom and Alan are using completely different rationales to prioritize, and then we just use a formula to rank our items, and that formula happens to put Alan’s favorites at the top of the list, Tom doesn’t feel heard.  The reality is that each person has a very good reason for the scores they offered.  The goal of this meeting is to have a really rich conversation about value.  I want to go beyond Reinertsen’s goal of getting our priorities right.

I want the whole team bought in to our decisions.  The conversation about the rationale helps us get there.

Then we sorted the list, highest value score first.  This was interesting - we saw a lot of obviously important items bubble to the top.  Some of them were very large.  We talked about how people felt about the results - what was missing that they felt should have been higher.  

The magical calculation

Then Michael, an internal coach, spoke up, and suggested we try a weighted-shortest-job-first score.  To do this, we divided our total value score by the cost (the value/cost column in the picture above).  A number of items that were small but valuable jumped higher up in our list.  This led to another valuable conversation

So we’re done, right?

Does the WSJF scoring solve all prioritization problems?  Do you work on items in exactly that order?  Not exactly.    We did another activity to lay out our work into our roadmap, and this led to further conversations about the capabilities of different teams, dependencies with other groups, and the like.  It’s not a perfect technique, but it was an incredibly valuable input for us.

For more on  managing a portfolio, tracking and prioritizing work according to its value, and effectively aligning business strategy with development work, join our Portfolio webinar series.

Alex Pukinskis

I’ve been reading a lot lately about the concept of enterprise agile and how the heck to do it. Agile development roots point to a very team-centric concept. And its success has piqued interest from other teams, other business units, and larger enterprises when it comes to scaling agile faster, better and easier. In fact, more than 61% of VersionOne customers recently said they’re in the process of scaling agile across their organizations.

The potential of agile is awesome… but it can be difficult to successfully adopt. For people who have been there, they can tell you it’s hard…but worth it. If you’re planning an enterprise agile project and worry what growing pains you’ll run into, you’re not alone.

One highly effective approach I encourage you to look into is the concept of Scaled Agile Framework (SAFe). Ever heard of it? Dean Leffingwell, a renowned methodologist, coach, entrepreneur and author is giving a presentation on SAFe which you won’t want to miss:

AgileLIVE Webinar:“Accelerate Enterprise Agile Adoption with Scaled Agile Framework”
Join your peers for this two-part webinar series. Register Now!

Part I – Monday, May 13th at 12 Noon EDT
Join Dean Leffingwell for an overview of SAFe, a publicly-accessible knowledge base of proven lean and agile practices for enterprise-class software development. You’ll learn how SAFe enables you to:

• Deliver business results that scale
• Keep your development system – and enterprise – lean
• Increase responsiveness to rapidly changing market needs

Part II – Wednesday, May 22th at 12 Noon EDT
Join us for a look into how VersionOne supports SAFe and helps accelerate adoption of enterprise agile. Andy Powell, Product Evangelist and Scaled Agile Framework Program Consultant, along with Lee Cunningham, Enterprise Agile Coach, will focus predominantly on the Portfolio and Program levels of SAFe and will demonstrate how VersionOne provides:

• Metrics that enable your business leadership to make more informed decisions
• Visualizations to help program managers pinpoint areas of risk
• Collaboration capabilities to capture the “why” behind key decisions

If you can’t make this series, no sweat. The focus of this year’s series is helping organizations maximize the benefits of enterprise agile, so stay tuned for info on future AgileLIVE webinars!

More than 1,000 developers across 72 events will join together on June 1-2 for National Day of Civic Hacking. Their mission? To use publicly-released data, and code to solve challenges relevant to our neighborhoods, our cities, our states and our country.

Here are 10 reasons why you should join:

1. Make a difference while building your local Agile and open source community
2. It’s only one or two days! And it might also open minds, hearts and doors to work that extends us beyond all of our “day jobs”
3. 24 data feeds and 17 federal government partners will lead to some great hackathon magic
4. President Obama and Todd Park, National CTO, are opening the White House for hacking via a lottery, and as a demo platform for the best applications
5. All this work will help the government open more data and thus create a better informed public
6. Tim O'Reilly will be proven as a prophet and general good guy for helping promote open source, open data and hacking for the last decade 
7. Get $200 off your registration for our RallyON conference by joining us to hack with the team from the National Renewable Energy Lab in Boulder
8. Your volunteering opens your eyes to the role of citizen engineers in solving the world’s toughest problems
9. Don’t have an event near you? Join a Rally team remotely using FlowDock and AgileZen
10. Support a culture of hacking that can lead to continuous innovation in your own organization

As part of our Rally for Impact efforts to help create and mobilize citizen engineers that are technically, environmentally and socially responsible, we are a proud sponsor of the National Day of Civic Hacking. Thanks to organizers like Code for America, Innovation Endeavors and Random Hacks of Kindness. And thanks to the organizational skills built by Second Muse, sites are finding great local and state resources.

Please consider joining, sharing and re-posting about National Day of Civic Hacking in your company and community

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

I recently read the excellent and fascinating book “The Power of Habit” by Charles Duhigg. The book doesn’t only cover habits of individuals, but also habits of communities and organizations. Reading it reminded me of a conversation I had with our CEO, Robert Holler about V-Days.

V-Day is our monthly company-wide gathering that brings everybody together to keep them in the loop as well as connected to each other. Family members, friends, and even job candidates are also invited. V-Day starts with lunch in the Game Room, continues with a break for everybody, reunites everybody for short presentations by each department about the last month, and usually ends with a “keynote” address by Robert.

The result?

• We generally feel informed about what is going on in the company
• We enjoy hearing the update rhymes Maggie finds the time to create about the Services department.
• We get to know new (and old) team members during lunch and the break
• We meet spouses and kids of co-workers, and they get to see where their parents go during the day
• We build shared memories

So what is the link between V-Days and The Power of Habit? I’m abbreviating a bit here, but you can build a habit by deciding on a certain routine that follows a certain cue – and practice it until it starts to be a habit. So non-habitual routines can turn into habits. However, they can also spawn additional habits by creating scheduled events that foster certain routines. For creating certain organizational behavior or company culture, the trick is figuring out which habits are most prominent in them, and which corporate event would most encourage those habits.

V-Days are a great example of that elusive “habit-fostering event.” They support three of the most prominent company habits – which also happen to be quintessential to agile teams: (1) Remember and share information that concerns others, (2) Interact with other people in VersionOne on a personal level as well as a professional one, and (3) Remember to acknowledge great work getting done.

I asked Robert if he had read the book, but he had not. Nevertheless, V-Day makes for a great illustration of many of Duhigg’s points, and IMHO a company-wide regular and fun get-together like this is one more secret to building agile culture.

 

It's been just over a week since Rally's IPO on the NYSE under the symbol RALY. We're settling back into our everyday work, and as I look back, I am again humbled to be one of the companies that trade in the public markets, and proud to be listed on the NYSE.

The morning of our IPO, I got to see Rally's logo on the front of the iconic NYSE building, I stood on the bell podium and pushed a giant green button with our founder Ryan Martens. And I toasted (with orange juice) enthusiastic employees in their offices around the world live from the bustling trading floor. 

But what struck me most throughout that day, and the days following, was the gratitude I felt. Tremendous gratitude. 

Thank you, Rally team. Rally is made up of individuals who are smart, committed and passionate. I am humbled that I get to come to work with you every day.

Thank you, customers. We work with and constantly learn from our customers and users. We continue to look to our customers as guides and partners, many of whom are helping redefine their industries through innovative software-powered products and services. We dedicate our success to date and our focus into the future to them. 

Thank you, partners, vendors and community members. Rally's ecosystem is strong and vibrant, and I know we are lucky to have those support systems all over the world.

In the midst of a lot of really hard work, we've had some fun and celebrations over the last week or so. Below are some of my highlights:

Here is a video of the NYSE opening bell ceremony:

Later I was proud to represent Rally, and our customers in talking with the media about a very special day for our company. Here's one take by our Boulder, Colorado-based Daily Camera.

Most fun for me as someone who values our culture so highly, here are a few photos of our employee celebrations that took place nearly simultaneously around the world.

Thank you for joining us on this journey, it's been – and will continue to be – a great ride.

Tim Miller

“A four-hour remote meeting with four geographies spanning and nine time zones AND I walked out more energized than I walked in.”

- Brent, product line manager in our Kirkland, WA office.

We just had our quarterly portfolio steering meeting, where we take a holistic look at our strategies and roadmaps across the company and make adjustments.   As Rally has grown, we’ve added engineering locations all around the world, and so this meeting involved engineering directors and product line managers in Helsinki, Raleigh, Boulder, and Seattle.  

In the past, I’d asked everyone to come to Boulder for a day for this kind of work, but the carbon footprint for the meeting goes way up when you do that.  And, five people would have spent a day or more in travel time.  So this time we decided to do the meeting fully distributed.

A four hour distributed meeting?  Sounds horrible, to be honest.   And I was worried about how we’d stay focused and get our work done without someone developing deep vein thrombosis from extended sitting.  But with a few of the old tricks, and a couple of new ones, we were able to make it work.  

Start with good video/audio

We’ve invested in Lifesize high-definition video units, which help a lot not only in direct communication, but also indirect - you can see when someone’s standing up, pacing around, started eating lunch, or left the room on a break.  Seeing the view out the window helps the group come together, too.   We watched the sky turn blue and black behind Otto in Helsinki, which reminded us of how late he was staying for the meeting.   We saw the sun brightening the harbor near Seattle, which reminded us that people were just getting started with their day out there.

Make content available in advance

This kind of meeting has a lot of readouts.  We did 7-minute readouts from the owners of cross-cutting strategies, and 7-10 minute readouts of roadmaps for each product line.  Some of these were available ahead of time, and we were able to spend more time discussing the topic and less time orienting around new information.  

Meetings like this are like board meetings, and Brad Feld’s advice on creating a board package is really relevant here.  Next time I’ll probably put together a package and send it out (as faciliator) rather than simply asking participants to share their content before the meeting.  We’d have had much more time for discussion if we had done less reading out.

2 conversations at a time

When I’m facilitating an in-person meeting, one of the working agreements I often use is that we should have 1 conversation at a time.  But with this meeting, we tried explicitly having 2 conversations at once - the out-loud conversation, and a parallel thread in Flowdock.  This took some getting used to, but it had some benefits.

As each person read out on their area, I asked other participants to note #surprises, #puzzles, #risks, and #dependencies in Flowdock.   This led to the following:

1. Participants often saw their own personal reactions corroborated by others, leading to ‘+1’ comments, which made it easier to discuss uncomfortable observations.
2. We didn’t have to do small group reaction debriefs.  Often there is an emotional response to a presentation that leads to a ‘need to be heard’.  Flowdock enabled us to meet that need, and that meant no further discussion was needed on many of the items.
3. We had an electronic record of these items.  For #puzzles and #risks, this produced a set of things we could easily carry out of the meeting and go forward.
4. Michael Ball, our internal coach, started noting the agenda items in the flow as we started new agenda items, so we could group the reactions by agenda item.

Also, as a facilitator, time management was easier.  As we ran out of time on a topic, I didn’t have to worry about evaluating whether the discussion should continue.  I simply said, “Ok, we’re going to move on, but whoever’s interested can continue this conversation in Flowdock.” A few people would stay engaged in typing, but usually the majority of the group would focus on the next area.  For a meeting that’s more about strategic alignment than precise agreement, this worked well.

Keeping people engaged

Whenever I sit on a call for hours, and I try to stand up, I realize I should have taken a break sooner.  With big, distributed steering meetings it’s critical to do frequent breaks - we stopped for 5-15 minutes every hour.  Set a precise time to come back together so people can plan their calls, bathroom visits, or whatever.  

When I facilitate in-person meetings, I usually use what my colleague Stephen Younge refers to as a ‘digital hat rack’ - laptops and phones get stacked on a table by the door.  You can leave your phone on, and you can answer it if it rings, but you can’t be texting and reading email the whole time.  This leads to deep engagement, focus, and participants demand more progress and effectiveness.

But for a distributed meeting, we’re stuck with the electronics.  What I found as I glanced around the room in Boulder was that everyone had Flowdock up.  Some people had it full-screen.  Others had a split-screen - half email, half Flowdock.  The Flowdock desktop client beeps as new messages come in, and this helped pull people back into the meeting; it prevented them getting completely lost in email for the most part.

The reality is that the bar is much higher in a distributed meeting when it comes to facilitation.  You have to keep the meeting focused and interesting for everyone.  There’s a certain amount of positive human feedback that happens when you’re all in the same room - you feel good and productive simply because you’re working together, even when the meeting is unfocused.  

When the group is distributed, that part gets stripped away, and you really have to make sure the work is important, people are prepared, you have exactly the right people (not too many), and that you’re making good progress if you want people to stay engaged.  Flowdock was a great help in this.  

Brent wrote later that Flowdock created  “some great dynamics: there was a balance of power with each person having a voice; conversations were focused without friction so they seemed to use time better.”  Is that what you need in your next steering meeting?

Alex Pukinskis

As we prepare for RallyON, our annual user conference here in Boulder, I got to thinking about some parallels in my life as a purveyor of eggs. Our Rally staff is well familiar with the dozens of eggs I bring each week from our small farm, laid by my varied chicken population. They sit in cartons at the feet of my stuffed penguin muse, Bernard. Bernard nurtures and guards those eggs like any male penguin (March of the Penguins, anyone?). But what does this have to do with a user conference? Back to the eggs, and their source: the hens that lay them.

We have several nest boxes back at Martens Farms Incorporated, each shared by the many hens that are laying eggs. Interestingly, the hens are only in the nesting boxes to lay eggs; they are purposeful in that visit. Each hen contributes to the daily egg production, and is identifiable by the egg itself. When we gather the eggs, I know that our Bantams lay the small white ones (most of their energy is put into growing flamboyant feathers), our Araucana lays the light blue ones, and the very large brown eggs are from our Orpingtons.

Where am I going with this? In our Agile practices we collaborate across roles, across functions and across projects, contributing to the common vision and organizational goals. We share nest boxes (or in office parlance, cubicles or open space) to facilitate that collaboration. And we trust and celebrate each team member's unique and valued contribution (blue eggs!). The overall Agile organism–or organization–is bettered and team members interact in ways that serve each and all.

When we come together as a cross-functional group, removing even company and organization boundaries, we all get better. We share a nest box of ideas, new ways of thinking, and open minds to the different colors of eggs in our collections. RallyON is just such a place, where collaboration is celebrated, innovation is fostered and practices are developed or re-defined. I hope you'll join Bernard and me for this year's conference, where we'll carve a new path forward for Agile leadership at scale. And who knows, maybe I'll bring over a few blue eggs.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

@import url("https://fast.fonts.com/t/1.css?apiType=css&projectid=70fce34d-5f4e-4297-b6b0-bdb0ec1fb0a5"); @font-face { font-family:"HelveticaNeueW01-65Medi"; src:url("/sites/all/themes/rally/fonts/helvetica/07fe0fec-b63f-4963-8ee1-535528b67fdb.eot?#iefix"); src:url("/sites/all/themes/rally/fonts/helvetica/07fe0fec-b63f-4963-8ee1-535528b67fdb.eot?#iefix") format("eot"), url("/sites/all/themes/rally/fonts/helvetica/60be5c39-863e-40cb-9434-6ebafb62ab2b.woff") format("woff"), url("/sites/all/themes/rally/fonts/helvetica/4c6503c9-859b-4d3b-a1d5-2d42e1222415.ttf") format("truetype"), url("/sites/all/themes/rally/fonts/helvetica/36c182c6-ef98-4021-9b0d-d63122c2bbf5.svg#36c182c6-ef98-4021-9b0d-d63122c2bbf5") format("svg"); } .rallyon-container { background: #fff; border-top: 6px solid #ED1C24; box-shadow: 0px 1px 1px 1px #ccc; clear:both; color: #000; padding: 24px; width: 570px; } .rallyon-container, .rallyon-container p { font-family:"HelveticaNeueW01-65Medi"; } .rallyon-container .left-container { display: inline-block; margin-right: 10px; vertical-align: top; width: 311px; } .rallyon-container .left-container p { font-size: 14px; } .rallyon-register img { box-shadow: 1px 1px 1px 1px #999; } .rallyon-container .right-container { display: inline-block; } .rallyon-schedule { background-color: #E8E8E8; border: 1px solid #D7D7D7; padding: 15px; width: 210px; } .rallyon-schedule p { font-size: 14px; margin-bottom: 0px; margin-top: 6px; } .rallyon-schedule p span { color: #777777; display: inline-block; font-size: 12px; margin-bottom: 6px; } .rallyon-schedule h3 { color: #F50A29; font-family:"HelveticaNeueW01-65Medi"; font-size: 20px; margin-top: 0px; padding-top: 0px; } Ryan Martens

Before I joined Rally full time, Ryan and I sat down in 2003 and talked about what we wanted to do this time around. We had built other companies together and knew each other pretty well at that point. Though we loved very different things, we shared a worldview that was harmonious and compatible. I wanted to build a company of real scale. I knew that I wanted to have a tremendous impact on our community, on our customers, and on our employees. I wanted to build something that wasn't just a build-to-flip company.

So we created Rally. We hired our first group of developers, many of whom stood with us today, sharing our excitement on the floor of the New York Stock Exchange. Today's achievement represents a goal that was only a dream when we started.

Agile is not just about transforming the way organizations manage the software development lifecycle. It's about creating an environment where people truly love to come to work. It gives me great pride that we can have an influence on that. Ultimately, work is just part of our life.

I'm exhausted. I'm excited. I am so very thankful to all of our employees, our customers, and to everybody who has had even a small hand in supporting Rally over the years. And now I think I’m going to go to bed and sleep for 18 hours.

 

Tim Miller

We have lots of conversations with customers about how testing should work and when it should happen. Often, customers want to have an ‘in test’ state, or column on their boards. Agile coaches often cringe at this because agile approaches generally don’t prescribe a test ‘stage’ for features - the idea is that developers and testers should work together to do development and testing at the same time.

But a new pattern is cropping up on kanban boards, and I’m now comfortable saying that it’s ok to have a test column on your boards.

It just needs to be LEFT of the dev column.

Take a look at this team’s kanban board:

They work on testing before starting coding. Before a story leaves that column, they agree to:

• check existing coverage around the story
• have a conversation between dev and testers about the scenarios that matter and how they should be tested.
• identify needed usage and performance gestures.

Many of our teams have created columns like this, because putting on the testing hat before the story even begins uncovers issues much faster (and at lower cost) than waiting until after the story has started.

Before items can leave the “Dev/Test” column, the team agrees that:

• All acceptance criteria are met, or moved to another story.
• Standard Definition of Done for stories has been met
• Automated test, usage, and performance gestures have been implemented for all workflows
• A walkthrough has been completed on a local machine with a tester on the team - someone sitting within 10 feet of the developer.

When are you doing your testing? If you implemented a test column before your dev column, would you deliver value faster?

Alex Pukinskis

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

- Agile Manifesto (agilemanifesto.org)

In case you weren’t aware, this is the 12th Principle of the Agile Manifesto and it is often translated into “inspect & adapt.” Of the 12 principles, this is definitely the one to which everyone can easily relate. The team should look at what they are doing, look at how they are doing, and adjust. This is primarily for the team, and I would argue that it’s mostly about the process (and maybe people stuff), but it could be around the product and/or project if we are doing this in respect to a specific release, or even the outcome of the sprint.

With Scrum, there is a ceremony (a.k.a. meeting) called a Retrospective. Other frameworks and processes have adopted the spirit of this meeting, and there are a bunch of creative ways to conduct the Retrospective. If they are kept fairly informal, transparent, and candid, then they can be hugely valuable — especially when they are actionable.

But this article is not about the Retrospective. Instead, it’s about the terms and maybe even the way we speak of the concept “inspect.”

inspect. v. To examine critically or carefully; especially, to search out problems or determine condition; to scrutinize.

If you’re development shop is worth its salt, then you are constantly inspecting. Let’s face it, the feedback loop with following iterative development, using continuous integration, employing automated testing, and on a cross-functional team is really tight. This means that we are constantly re-digesting information from our feedback loop — so inspection is constant.

I propose this… instead of “Inspect and Adapt,” shouldn’t we “Innovate and Adapt?” Now I cannot take credit for this change of terms. I was driving home one day from the office and I heard a post-season interview with the Atlanta Falcons’ head coach Mike Smith. He was talking about the fact that the team has reviewed all the tape from the year and now it’s time to innovate and adapt. He went on to say that seeing one’s issues and/or challenges is not enough; they have to find ways to beat the competition and be better — that requires innovation.

inspect. v. To alter; to change into something new.

So instead of simply looking and digesting, let’s imagine and innovate. Once we innovate, we adapt the new ideas to our team; we continue inspecting our feedback loops; and we continue our innovation.

Sometimes when you innovate, you make mistakes. It is best to admit them quick, and get on with improving your other innovations.

- Steve Jobs

I got an email this morning from our Community Manager listing all the agile events we’re doing this spring and wow – we’re gonna be busy! Scope out the list…

Is one of these events in your area? Come out and see us. Don’t give a crap? Share this list with someone who might:

AgilePalooza Twin Cities. Private day @ Target on 4/11. Public day on 4/12. http://agilepalooza.com/mn2013/

ATL Javascript Group. Monday, 4/15 @ 7PM @ Ogilvy. http://www.atlantajavascript.com/events/81796572/

Mile High Agile: Denver, CO. 4/19 http://milehighagile2013.agiledenver.org/

PMI Region 6: St. Louis, MO. 4/19 – 4/21 http://www.stlpmi.org/

LeanKanban 2013: Chicago, IL. 4/29 – 5/1  http://lkna.leankanban.com/

PMI Nashville: Nashville, TN. 4/29 – 4/30

Project Management Symposium: Innovating the Future. http://www.pminashville.org/downloads/newsletter/doc_download/84-symposium-flier-with-schedule

PMI Augusta: Augusta, GA. 5/2 – 5/4

PMI Region 14 Leadership Conference. TBA.

Kansas City Developers Conference. 5/3 – 5/5. Kansas City, MO http://kcdc.info/

Scrum Gathering Las Vegas. 5/6 – 5/8.  http://www.scrumalliance.org/events/610-las-vegas-

AgilePalooza Seattle. Private day: TBD — 5/16.  Public day:  5/17 Seattle, WA http://www.agilepalooza.com

Gartner PPM Summit. 5/20 -5/22 Washington, DC http://www.gartner.com/technology/summits/na/program-management/

Path to Agility. 5/22 and 5/23.  Columbus, OH.  http://www.thepathtoagility.com/

ADP West. 6/3 – 6/7. Las Vegas, NV. http://adc-bsc-west.techwell.com/

 

Catch a complete list of all agile community events or list your own event at AgileSherpa.org.