by Jenny Boronyak | Dec 10, 2014 | Agile, Business Analysis, Collaboration, Product Development, Project Management |
A clearly-defined Definition of Done is absolutely essential to agile software development. At the end of every sprint or increment, software is demonstrated to the product owner and relevant stakeholders to make sure that the increment is done. But too often, we end up accepting the work completed during the increment even though it isn’t truly done yet – “DONE-done,” as we call it at Enfocus Solutions. A Definition of Done creates a shared understanding of what it means to be finished. According to AgileAlliance.org, the Definition of Done is a list of criteria that must be met before a product increment is considered “Done.” The Definition of Done is also an expression of the team’s quality standards. A more precise Definition of Done is often associated with the delivery of higher quality solutions. Generally, the team will increase their velocity as their Definition of Done gets refined, because they will improve release planning and spend less time fixing old problems. The most important function of the Definition of Done is that it provides a clear description of what it means for an increment to be done and ready to be implemented. It helps us avoid misunderstandings and miscommunications, and makes sure that there’s transparency around what the team is doing during the sprint. It is difficult to pin down a Definition of Done that suits all circumstances. Each organization needs to define their own definition; the checklist found in this pocket guide is meant to serve as a guideline for building your own Definition of Done for an iteration. Here’s a couple tips for dealing with the Definition...
by Jenny Boronyak | Dec 3, 2014 | Agile, Product Development, Project Management |
At Enfocus Solutions, we’ve adopted much of the Scaled Agile Framework®, the premiere scaling framework for scaling agile developed by Dean Leffingwell and Scaled Agile, Inc. One of the many aspects of the framework that makes it such a useful tool is Leffingwell’s concept of Inspect and Adapt Workshops. Building on one of the principles taken from the Agile Manifesto that, “at regular intervals, the team reflects on how to become more effective,” SAFe® incorporates the Inspect and Adapt (I&A) workshop at the end of a release or Program Increment (PI). According to SAFe®, “I&A is to a Release Train what the sprint demo and retrospective are to a team—a regular, programmatic, time to reflect, problem solve, and take on improvement actions [to] identify actions needed to increase the velocity, quality and reliability of the next increment.” When discussing the Inspect and Adapt workshop, the Scaled Agile Framework® describes I&A activities occurring only on the program level. However, at Enfocus Solutions, we like to take it a step further and carry out Inspect and Adapt activities at every level: portfolio, program, and team. This way, we review the solution constantly, making it more likely that we catch problems and issues as they happen, instead of during a demo with a stakeholder. At each level in the organization, there are activities that can be performed that will help ensure your teams are continuously inspecting and adapting, not just during program level events: Portfolio—A formal Performance Evaluation (or, inspection) should take place to ensure the Program Portfolio achieves the desired performance by measuring business outcomes against predetermined KPIs. There may be...
by John Parker | Dec 1, 2014 | Agile, Project Management |
You guys did it again! Our last webinar, Enterprise Agile Project Management, was an incredible success. There were many thoughtful questions asked that I unfortunately didn’t have the time to answer. The Webinar Q&A can now be downloaded alongside the rest of the webinar resources, including the recording and slide deck. Here are a few of the questions asked during the webinar: Q: Today, the role of scrum master is the same as Project Manager in traditional projects, they just use different terminology and PDM process. Is this correct? A: A Scrum Master and a Project Manager are not the same. Organizations that have made this assumption have seen disastrous results. The traditional Project Manager is a leader, a decision maker, and a planner who manages the project and his team, and is the person accountable to the business for accomplishing the project objectives. The role of the Scrum Master is more of a coaching and facilitation role, a role that sits between the project and the customer. Q: Is Project Manager role the same as Product Manager role in this presentation? I’ve just submitted for a position that states the role as a PO and went on to state tasks as a PM. I personally don’t think this is a successful set up. Please advise. A: No, the project manager and the product manager are not the same role. The project manager is responsible for managing releases and associated business change. The project manager also manages assignments among multiple teams when multiple teams are involved. The product manager is responsible for determining what new features are needed in...
by Jenny Boronyak | Oct 23, 2014 | Agile, Business Analysis |
Wow! More people than ever showed up to the Enfocus Solutions Webinar Series last week when CEO John Parker presented The Agile Business Analyst. There were so many questions asked that we couldn’t even begin to answer them during the webinar. The original plan was to publish the Q&A as a blog post, but there were just way too many questions to do that! So, below are a few of our favorites. All answers were provided by the webinar presenter, John Parker. It was really hard to pick just a few. If you’d like to read the answers to all of the questions asked, download the complete Q&A. Q: How do we keep track of the changes made in a system if we don’t document them? A: The changes are documented with user stories, maintaining clean code, and writing an efficient level of system documentation. Agile does not mean “producing no documentation.” Agile documentation is lightweight and sufficient. Q: What do you recommend for system documentation that must be maintained? At the end of the day, organizations need a document outlining business process, business rules, data rules, etc. A: This information is usually maintained in a collaborative business architecture and maintained separately from the team. When an Epic is defined, necessary changes to the business architecture are identified as change impacts. These changes are further refined as Epics are decomposed into Features. Stories simply represent changes to the business architecture. I did not discuss all of this in the webinar, but this is a key part of agile portfolio and program management. Q: How do you make agile work...
by Jenny Boronyak | Sep 10, 2014 | Agile, Uncategorized |
When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development. But there’s so much more to being agile than delivering software products iteratively and incrementally. If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands. On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently. In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business: Enterprise Agile Delivery The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs. Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements: Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using...
by Jenny Boronyak | Jul 25, 2014 | Agile, Uncategorized |
Business agility is more important now than ever, according to a recent report by Forrester Research. In the report, they define business agility as “the quality that allows an enterprise to embrace market and operational changes as a matter of routine.” As Forrester astutely points out, seventy percent of the companies that existed on the Fortune 1000 list ten years ago are no longer in service—the number one cause being the inability to adapt to change. Many organizations have adopted agile methods for software or product development. Agile methods have helped organizations deliver more rapidly, increase customer satisfaction, and improve quality. However, agile development alone does not make the enterprise agile. An agile business must be able to make rapid changes that affect people, processes, data, technology, and rules to support threats and opportunities in the market. The Lean Business Agility Framework™ is here to guide you through choosing the methods that will enable change and achieve business agility in your organization. There are many great existing frameworks and methodologies for implementing agile best practices. However, the Lean Business Agility Framework combines all best practices into one comprehensive guide. The Lean Business Agility Framework was developed by Enfocus Solutions to help organizations visualize what is needed to transform to an agile enterprise. The framework incorporates current trends and integrates various methods from sources such as the Scaled Agile Framework® (SAFe), ITIL®, Lean Thinking, and Lean Startup® into a cohesive approach for moving to business agility. The framework is intended to serve only as a guide and requires an organization to selectively choose the methods that best fit their organization...
