Articles
How to get the most from (SCRUM, etc.) Agile
Scroll down for more...
How can you guarantee success in your Agile projects? You cannot. But, there are a few key ingredients that the most successful Agile projects all share, and this article will focus on those delivery best practices. The Agile methodology was created and should be adopted with three core benefits in mind (among others). They are:
Success with Agile is not hard, but it does require a fresh look at product delivery. There are things that each member of the project team – whether manager, analyst, architect or engineer can do to maximize efficiency, build sustainability, and drive quality into your projects.
0 Comments
SCRUM Agile maximizes the power of teamsIn Scrum Agile you see that the ‘team’ is the core of any project. This article discusses the steps, principles and skills required by the members of the Scrum team as they enter the iterative or "Sprint" phases of the project. I will assume you have some knowledge of Scrum Agile practices, so many details will be left out, but I do repeat some of the basics below, so please be patient if you already know this. This article is focused on Scrum team members. If you are a project manager, delivery manager, etc., this may not answer all the questions from your point of view, so feel free to peruse my other articles, but you should read this, too. Scrum Agile is a team-based approach to project development, and it agrees with the saying that if we do not pull together, we will most certainly pull apart. You will find that Scrum methodology works best when the team follows all practices fully and honestly. Agile is a self-correcting process when it is followed faithfully. If you understand Scrum, respect the team, and commit yourself to your role in it, you will help to deliver the best IT experience for you and your team and make it more likely that you meet or exceed your customers' expectations. These Sprints should used for technical and architectural work that would prevent your team from Sprinting at full speed What is the source of technical work in your project that does not come directly from User Stories? You will find it comes up before, but also during Sprint work, and we do not want to slow your Sprints with this work. Sprint Zero is the technical Sprint phase that precedes a new release phase, and is also known as your "architectural runway". We use it to prepare for development Sprinting. This runway is like buying the land, clearing trees, and installing water and sewer lines, before building a house: it is essential, but does nothing to get your home actually built. Your architectural runway is for technical work that will lay the foundation for your team to Sprint at full speed. We use this time to set up environments, get system access for our teams, prepare code repositories, etc. None of this creates application functionality, but you cannot build the product without it. After this, throughout the Sprint phase, technical debt is accumulating and should be cleaned up regularly. This work should be handled with Synchronization Sprints (or Sync Sprints, for short). Code clean-up, performance tuning, data integration, test data clean-up, server expansions all should be managed during Sync Sprints. We believe you will need a Sync Sprint after every three regular Sprints. It may seem odd, but you must “slow down so you can go faster”. One problem all IT departments face is the difficulty of providing early, frequent and clear signs of both progress and value delivery. Has this happened to you?... You continue to move forward month after month until a year or more has passed with only limited evidence of your impact. Your customer is frustrated and you feel your work is overlooked. Agile is designed to get better feedback, sooner, especially with our larger systems. In fact, Agile Down-to-Earth states that delivering high value software is the most important measure of project success. But, how do we go from a great vision to delivering high value, sooner? Our largest systems may take many months to build. Agile works even better when those systems are built and delivered in small increments, but where do you start? And, how do we keep building value early and often? The first release is the most important. Before we go too far, we must be sure that we are building what the business wants and will use. Look for high-value features, but keep your first release's scope very small so it can be built quickly - never more than six months from Feasibility to Realization. Get it implemented; learn from it, gathering as much customer feedback as possible. This is the goal: we need to hear more feedback from more users, earlier. Keep your teams and stories small, so we can move quickly and accept change more easily. As they say, "do not bite off more than you can chew". Scrum development is an excellent discipline for funded project initiatives: the customer is provided with frequent progress updates and allowed to modify the course of their initiative. But, what is the best method for handling defects and the many smaller enhancements being managed by your lights-on teams? Scrum may be too rigid and inflexible for a mature team that is just working down the fast-moving Backlog of minor requests and urgent issues of a platform. This is where Kanban may provide a better fit - keeping our development teams more fully engaged, empowered and self-regulating. Kanban, (which means, essentially, 'the sign you can see' - a plackard, sign or billboard) started as a scheduling system for lean and just-in-time (JIT) manufacturing that has been adapted for IT. There is no ScrumMaster on a Kanban team (but you still do Scrum!). There is no planning poker or Sprint retrospective. In fact, there is no "Sprint". Each member of the team pulls as much work as he/she can handle in a continuous flow. Development is self-regulating. Cycle time and Cumulative Flow analysis allow the team to identify bottlenecks to their efficiency and make adjustments to continuously improve. Ideally, Kanban encourages maximum through-put and offers the most efficient use of IT development resources who are not working on just one project. NOTE: This article expresses the explicit approach to requirements development recommended by Agile Down-to-Earth - take it or leave it as you wish There is one project phase that is more often identified as a source of eventual project trouble than any other: Requirements development (aka Product Planning). [as you can see - this article focuses on 'project' requirements development, but the principles apply to even small enhancements - Paul] Now this may seem counter-intuitive, since it is Agile that is designed around embracing 'fuzzy' requirements, but that is not a true reading of Agile in most cases. Agile works best in a 'mature' planning organization. The better you plan, the more effective your Sprinting can be. The goal of this phase is to completely understand the product to be delivered (but not to deliver any of it as some are tempted to do). This phase can be very short and still be successful, but often it is when we spend too little time or resources in this phase that problems arise. Agile Requirements Development is focused on discovering and writing the detailed User Stories and other requirements needed to enter the Risk phase of your project (see the 80/20 rule below). The requirements team should be entirely focused on that simple (sounding) result. We need to be sure we know what we want to build (and in what priority!) before we start to build anything. After this phase we can be more accurate with our resource requirements and develop cost estimates for the Sprint (development/build) phase. Lessons learned from other projects have shown that when we do not develop our requirements completely and do not focus sufficiently on User Story development, we set ourselves up for great difficulty later. Use this phase to know a great deal about what you are about to build before you start, and keep it small (hint: keep the entire project release to only six months). A User Story is just that. It is a non-technical description of what the user of a system desires or imagines. It is written from the specific user's perspective and it is at the core of the Agile method. It is NOT a specification. It is intended to be a user's view of a desired outcome, trusting in the team (the Scrum team) to apply their expertise to design and create the best solution in the time allowed. Due to the nature of Agile project engineering, it is also very necessary that the User Story be small - in other words, it describes something that can be fully built in a small amount of time. The process for developing User Stories varies, but in project work, it is assumed that you will take the business requirements at a higher level and break them down - level by level - to get to the actual Stories. This process may not be simple, fast, or easy, but it is essential to the success of Agile development that we break down our ideas into the smallest implementable parts before attempting to "Sprint" on them. Without properly formed Stories, Sprint development gets quickly bogged down into questions of scope and definition that obscure the solution and generate tension in the project team. User Story development is an essential skill and unique tool for building clarity and consensus in your project scope, and well-built stories will help the Scrum team to satisfy and delight your customers. What, you may ask, is a ScrumMaster? Does the thought of becoming one sound good to you? Does it sound like it is not for you? Are you not sure? Aside from the role of Product Owner, this may be the most important responsibility in the Scrum team. But, unlike the name sounds, you do not need to be a 'Master' of Scrum to be a good ScrumMaster. In the opinion of ADTE, any team member can (and we feel should) become a ScrumMaster. The role can be a part-time one, so any team member can do it and still retain their skills and responsibilities. You will learn from the 'inside' what it means to try to keep an Agile team running at peak efficiency. You will gain exposure to the kinds of impediments we all face, plus gain experience with new ways to overcome them. A ScrumMaster, in our model, is a member of the team - not a separate role. Success of the team is their success and of course, failure is theirs to share, too. In this role you will not 'tell' the team what to do. You are not a 'boss'. But, you will be in a great position to show the team the impact of their work progress, help them make choices when the path forward is not clear, and be the team champion for Scrum and Agile. Each team must have a ScrumMaster. Agile guidelines suggest a team size of 5 to 9 individuals. That means most companies need many, trained ScrumMasters. That means that YOU should be a ScrumMaster! Also, try rotating this role across your project or platform team. Others will benefit, too. |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
September 2014
Categories
All
(c) 2016 - Agile Down-to-Earth All rights reserved |