Working With An Agile Mindset

Agile project management discipline allows for organizational transformations that yields more effective and quicker results

Working in agile is so different and rewarding than a traditional waterfall approach. I enjoy the self organized, collective decision- making requirements that are the real background of succeeding in agile.

It all began in Utah when a bunch of really smart guys white-boarded out a different way to get things done. It's now seeded as a practical tool in thousands of organizations. It's first and foremost a mindset, and I have enjoyed the excitement and energy associated with agile projects that yield amazing and impactful results.

Organizations spent too much time working in silos. You might never really know what others do. An agile project offers more than the opportunity just to get to know the other people in the company. It's a win-win team environment where everyone improves their own skill sets working cross-functionally and collaboratively.

Agile Versus Waterfall

I've built dozens of projects in waterfall. It's a much more strict process when timeline deliverable dates are dart throws and arbitrary, sometimes months away. Throw in scope creep, and timelines get pushed, project direction can lag, and the final output is impacted. When it comes to software development, agile lends itself perfectly to a polished final product.

The Mindset

Collective decision making is my favorite part of agile. Getting insights and directional ideas from a project manager and application developers is often fresh and rewarding. This collaboration can occur early in the process and later, especially because everyone embraces a continuous delivery mentality.

Guiding Principles

Agile offers flexibility in the build and delivery process, such as a key software development project. By following the basic agile principles, I've found that everyone knows and understands roles, responsibilities and the end goal.

When everyone on the team can be an advocate and proponent of change, that opens up the collective thinking of everybody. It doesn't matter which stakeholder has an idea, it's the simple fact that "you" can follow the Steve Jobs mantra, think differently.

The 20/80 principle allows a team to prioritize high-value aspects of the project first. How many times have you looked at the project scope and requirements and thought to yourself "where do we begin?" I often don't have a high level of interaction with the application development team. When an agile project is in motion, interaction with them is fun and rewarding. Especially, when the How and The What hit it's stride. As a big picture guy, I'll formulate the "What" leaving the developers to work out the implementation and code development of the "How." I demand frequent discussions to not lose touch with the 20% focus area.

Building user stories is a key principle. What's nice is, this isn't hard to do. Asking the team to behave like consumers, which they do when they are not in the office, yields broader insights. The traditional user story approach always works. As a (user), I want a (feature) to do something (value). At times the team will misinterpret user stories as requirements gathering, an agile no-no. The simplicity of user stories works for everyone and creates positive and interesting cross-functional dialogue.

Working in time-boxed sprints offers the highest level of accountability a project could ever ask for. I have found that this concept teaches young, up-and-coming developers a lot. With daily stand-ups to review tasks, you learn quickly the discipline of prioritizing. There is no such thing as a bad excuse. The requirements define the deliverable. If you miss, it has an impact on the team.

With predictable delivery, planning and delivery mean two different things. It's fun to teach this strategic thinking to the team and center on "little wins" or shorts bursts of success versus slogging through five pages of an overly thought out one year project plan.

Agile Foundations

When you stay focused on simple agile principles, everyone wins. It begins with having an agile mindset. I build it in to the DNA of the team's outlook and thinking. When individuals are forced to interact, good things happen. I've improved my own leadership style by listening to great team member feedback - agile gives them the right to be "agents of change" as part of the strategic approach to delivering a quality end product. It's how you respond to that change that makes the team better. Healthy, constructive dialogue is necessary but it should always fall back on how it impacts the user experience. Personal opinion and bias are nice, but I'm not building a mobile app for just myself.