Agile
There's the old saying, "You can't build a house with Agile." Well, I say bull! Agile is about the self-organiziation of the team, communication and cooperation to deliver value. I have written
on how to build a house with Agile. Builders do it all the time. Infrastructure does it too.
They just don't know it.
The point of Agile is to be, well, agile. To make changes, adjustments and moves to accommodate and achieve the greatest speed of progress for the project. One of the best ways to do that, it would seem, is to let people do what they do best. And that's Design, Build, Test and Deploy. So, in Agile, teams are built around the actual engineers, and not managers. That's why Agile does not have a Project Manager, but instead, a Scrum Master. And the reason for a Scrum Master? Well, as good as the developers are at coding, they are equally bad at staying focused and on track with their work.
So how does a PM relate to an SM? It's all a state of mind. At its core, they both are doing the same: understanding the intent of delivery by the team, keeping the team focused on the work and validating deliverables for the project. A Project Manager meets with the team, gathers an understanding of what the team intends to do in relation to the request of the Stakeholder, confirms the progress of the team and then announces completion of tasks and readiness for Deployment. A Scrum Master does pretty much the same, but specifically, that's all they do. Unlike a PM, they don't plan, create, or report budgets. They don't maintain Communication tools such Status Reports or Risk/Issue/Action Item logs. They don't communicate with or present road map planning to Stakeholders or Leadership. And one key item, they don't associate with outside or cross-matrix teams. At best, they'll have Scrum of Scrums with other Scrum Masters, but not actually team members. So their focus is much more channeled and boutique in nature.
As for the classic question, which is better, Waterfall or Agile? Well, Agile is, "for most of the projects, most of the time." Agile works great for project that can follow the Agile Manifesto: Self-managed teams, co-located that produce software with primarily verbally communicated requirements. That is, Agile works best when the people can just do their job, on that specific work and are allowed to be responsible for its delivery. So it's not so much which is better, but which is best for what you're doing in the environment you are in. Within Agile are components of Waterfall integrated into it's cycles. Although Agile doesn't do Status Reporting per se, they report status by the stories completed in the sprint and the demos that follow. And when the team has issues, they escalate blockers to the Scrum Master the same way they would to a Project Manager.
So exactly how do you build a house with Agile? Easy, the same way you do it with any other methodology or process. You conceptualize the design, then formalize it. Now it's Agile team, where you work with specific and formal self contained teams to execute their work. Plumbers do the plumbing, electricians do the electrical. At the end of the day, you are trying to get your MVP and looking forward to demo days. The MVP is what you need to work for your customer, and demo days are the inspections. Although house building follows a standard approach: Grading, Foundation, Framing, Electrical, Plumbing, Drywall, Flooring, Painting, Landscape, any of these csan be moved around to accomodate the MVP. Although you can't pour a foundation until you Grade the lot, you could in fact, work in drywall and electrical through preformatted framing back at the factory. And that may be needed to prove a design works as expected for the client and it will stand as an MVP to be incorporated into the grand vision at a later date.
Agile Manifesto
The Agile Manifesto created as the framework for a new way for software development is based on the following 12 principles:
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months).
- Close, daily cooperation between business people and developers.
- Projects are built around motivated individuals, who should be trusted.
- Face-to-face conversation is the best form of communication (co-location).
- Working software is the primary measure of progress.
- Sustainable development, able to maintain a constant pace.
- Continuous attention to technical excellence and good design.
- Simplicity - the art of maximizing the amount of work not done - is essential.
- Best architectures, requirements, and designs emerge from self-organizing teams.
- Regularly, the team reflects on how to become more effective, and adjusts accordingly.
These principles highlight one key point over all others: Communication! Constant and consistent communication amongst the team is paramount for success. And it's true in any other form as well, but Agile really drives it home. You have constant communication. And in doing so, the team members become more self-organizing, more self-reliant, and more self-confident to produce the work that is being asked of them.
What I Bring to the Table
For the past 10 years I've worked with Agile in corporate enterprise environments. I support the project effort in all aspects of Agile management to deliver the same concise and detailed communication of project performance and progress the Leadership is looking for to make the correct decisions in road map planning. Agile, in it's many incarnations, Water-Gile, Agi-Fall, Agile-Like, often takes on a life of its own, as more often than not, the enterprise team is not familiar with the true application of Agile, and will need coaching to get them fully engaged. Understanding that Agile is more than just stand-ups and sprints is is key here. The simple notion of the stand-up not turning into a status update pow-wow or a venting session requires a finesse that I can bring as a seasoned professional. I can support your environment with these key activities and so much more:
- Identifying true Agile team structure for proper development alignment
- Scrum Master role, leading the team in all aspects of Agile ceremonies
- Supporting Product Management in development of Stories
- Backlog grooming for Program Increment (PI) planning
- Supporting and mentoring team members in Story review and Planning Poker
- Communication of story completion and presentation for acceptance by Stakeholders
- Bi-weekly alternation of Backlog Grooming and Planning
- End of Sprint Demos and Velocity reporting extracted from the tools natively, or through manual manipulations
