What are the responsibilities of a Development Team in Scrum Development?

Recently, we posted a basic introduction to Agile development, particularly Scrum, and then followed up with a little detail on the Scrum Master, and the Product Owner. As a follow up and final post in our Agile-Scrum blog series, we’ll talk about the Team in Scrum Development.

As you are well aware by now, Scrum is a lightweight Agile project management methodology with broad applicability of managing and controlling all kinds of incremental and iterative projects. It is one of the most widely used methodologies due to its ability to deliver the best performance.

The development team in the scrum is designed to consist of approximately 10 people - give or take, depending on the project - who address complex problems creatively and productively. They are a team of professionals who are empowered by the organization to manage their own work. Team members are generally cross-functional and combine to bring to the table all skills necessary to create a product increment. A Scrum team consists of a variety of skills in the web industry ranging from JavaScript, Angular JS, HTML, CSS, web forms, MVC, and Telerik. Therefore, the team brings assurance to the client that they are dealing with your project efficiently to produce the desired results.

Responsibilities. The team can implement the final website and application from simple to complex highly integrated business web applications. The Scrum team, together and individually, is accountable for their actions and deliverables. It could be that each individual developer may have a specific skill but the whole team is accountable for web development.  There is a Scrum Master who is responsible for helping the scrum team understand the scope of the project and encourages everyone to maximize the value created by the team. The Scrum Master is responsible to the Product Owner and ensures that they understand how to arrange product backlogs to maximize the return on investment. The Master is responsible for facilitating the Team to implement events as expected. She or he also provides advice to those outside the scrum team on which interactions are valuable and those that can be less helpful. 

Sprint planning. The scrum team is responsible for creating a sprint plan in which they plan the events. Sprints usually consist of; daily scrums, sprint review, developed work, and sprint planning. The purpose of the sprint is to accomplish a particular task or deliverable. The lifespan of a sprint is usually one month and it allows for inspection, and adaptation of a process. They usually limit risks to complex matters that might arise when there is a long sprint. A sprint review or retrospective looks at the work accomplished and the work still on the table. A demonstration is sometimes presented and then next steps identified. Obviously, incomplete work cannot be presented to stakeholders.

Daily Scrum. The team is also responsible for the daily scrum. This is the time when scrum members ask the questions of ‘what did I complete yesterday?’ and ‘what do I plan today?’, and ‘is there any impediment that will prevent the team from accomplishing the sprint goal?’ The scrum master captures all the potential risks or issues that may delay the project and displays it to the team onboard. Only the development team is allowed to participate in the daily scrum. Each member is expected to be on time and participatory.

So, there you have it. This brings to a conclusion our series on Agile Development, in particular the role of Scrum management. And don’t forget that Extra Nerds is here for you should you need a team to manage and create your next IT project!

What are the responsibilities of a Product Owner in Scrum Development?

So, we’ve talked about Agile Development, particularly Scrum  and last month we dissected the role of the Scrum Master. Now you know the duty of Scrum Master. The Product Owner then, plays a different role.

The Scrum Product Owner is basically the lynchpin of a given project.  This individual needs to have a clear understanding of what he or she needs or wants to build as well as the ability to accurately convey this end goal to the other members of the project. They do this by using a product backlog (a list of necessary features and priorities for the final product), which we will discuss in more detail below.

Of course, so far this sounds like it could be the owner of pretty much any software project. Ideally, the Scrum Product Owner needs to have a good understanding of the target users, the competition, the market, and the general dictions of the industry for which the product will be developed. These requirements vary slightly, depending on whether the product will be used commercially or for internal objectives, whether it will be software or hardware, and so on. The important take away here is that the person who takes the role of the Product Owner needs to have a vision for what is to be built and who are going to be the end users.

So, to make sure that all members of the Scrum project understand and share the Product Owner's vision, s/he typically creates a backlog: a list of important features of the product, generally prioritized. In the agile development process, the product backlog is written during the sprint planning meeting - a meeting consisting of Product Owner, Scrum Master, and the entire Agile Team. Although all members of the meeting can contribute to the backlog, it is the Product Owner job to clarify the details of the backlog items and to establish their acceptance criteria. In addition, it is their job to estimate how many sprints will be required to complete each of the backlog items.

It is important to keep in mind that the Product Owner does not specifically define when each of the backlog features will be implemented. Rather, the owner's job is to motivate the team with well-defined and achievable goals. Team members know best their abilities and can, themselves, decide during which sprints – or releasable increments - they will be able to focus on in the particular parts of the backlog.

Yet another requirement for a successful Product Owner is flexibility or adaptability. During a development process, several project aspects can change due to unexpected complexities, such as a team member’s illness, insufficient funding, or any number of external problems. For this reason, one should not treat a backlog as a fixed document and must be willing to be dynamic as the project evolves.

The only thing one should keep in mind is that any changes should preferably be implemented outside of sprints. After the team starts a sprint, the backlog really needs to stay fixed so that the team can be allowed to be focused only on the sprint goals. If the project circumstances change dramatically during the sprint, the Project Owner can end a sprint prematurely and take a different course of action.

Finally, the Product Owner has to act as an interface between the client and the Scrum Team. This means he is responsible for both communications between the client with the product developers, similar to a Project Manager, as well as having the ability to relay any Team message to the client. To achieve this successfully, the Product Owner needs to make sure he spends an appropriate amount of time with both sides of the project.

We're going to post one more blog about Scrum next month when we go into more detail about the Development Team. Join us, won't you?

What is the role of Scrum Master in Scrum Development?

Delving a bit more deeply into the world of Scrum after last month’s post about the core concepts of Agile Development, particularly Scrum, let’s talk about the Scrum Master! First, a quick review…

Most people would be familiar with the general term “scrum” as the term for a rugby huddle in which teams discuss their strategy for the next phase of the game, while wiping the blood out of their eyes. But, Scrum has taken on a new meaning to us nerds and relates to software development in case of Agile and other types of project management.

Agile software development provides a platform and a step-by-step process by which the client reviews various deliverables or features of the product being created.  Scrum comes as a helping hand in case of software development and usually refers to a protocol followed by developers where all the members working on a particular project meet up to discuss the project. Usually with less blood, however.

The team members discuss any feedback from clients and changes suggested or approved by the project manager or boss type person. Developers discuss their respective piece of the project and that which they intend to work on next.  They may also discuss any roadblocks or issues which might need attention.  This process helps in keeping the project in a live and malleable form throughout development.  The person who facilitates and in a way moderates this process is the Scrum Master.

This master need not be a team lead or anyone in managerial position, but it definitely has to be someone from the team who is technically sound and well aware of the status of the project. S/he will follow up the work status of each of the member, request updates on what has been done and that which is still pending, determine the details of any issues that require workarounds or any other issues that have arisen during the initial stages. Usually the Scrum Master will ask questions like “what did you accomplish yesterday?”, “what are you going to do today?”, and “are there any potential impediments to your continued progress?”.

The Scrum Master’s role is not rigid or even necessarily formally defined. In fact, if the paradigm allows for it, different members of the team can take turns as the Scrum Master, allowing each member to be responsible for the proceedings of the project. This can create a level of ownership unparalleled in other methodologies and makes each and every member of the team to be responsible for the final product, for better or worse.

Scrum in software is an innovative concept and has been very effective. Many software enterprises – large and small - now follow this model even for software development models other than agile development.

Stop back next week when we talk about the Product Owner in Scrum development! And feel free to peruse our website to check out our services or see what our clients have to say about our work. We can do the same for you.

The Core Concepts of Agile Software Development, Particularly Scrum

In last month’s blog, we discussed Agile software development and why we think that it’s superior to the Waterfall.  Now we want to break down the core concepts, and delve into one of them in particular – Scrum. (And no, Aussies, we’re not talking about rugby).

The Dynamic Systems Development Method, or DSDM, mostly used in the UK, is probably the original agile development method. It existed before the term ‘agile’ had even come to pass, but is based on all the same principles we’ve come to know as agile.  

Extreme Programming (XP) is a more radical agile methodology, concentrating more on the software engineering process and addressing the analysis, development, and test phases with unique approaches that have a significant impact on the quality of the final product.

Scrum, a subset of Agile, concentrates on how to manage tasks within a team-based development structure.  Scrum is the most popular and widely adopted agile method, which is why we’re going to focus on it for the sake of this blog.  It’s relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades

Scrum is a lightweight Agile project management methodology with broad applicability of managing and controlling all kinds of incremental and iterative projects. It is one of the most widely used methodologies due to its ability to deliver the best performance. Over the last decade, Scrum has been revolutionized with significant investments of time and expertise.  It has garnered increasing popularity among software developers due to its proven productivity, its capability to act as a wrapper for a number of engineering practices that are promoted by alternative agile methodologies, and for its simplicity.

This methodology requires the use of development cycles known as Sprints. In software development, a sprint is a set duration of time during which specific work is to be completed and available for review. With Scrum, the owner of the product can work closely with the development team in order to identify and make a priority of the system functionality; this occurs in the form of a product backlog. This product backlog outlines non-functional requirements and bug fixes among other features, all of which are needed to deliver successfully a working software system. Priorities are driven exclusively by the client, or product owner, and cross-functional teams will estimate and sign on to come up with increments of the software created during successive Sprints. This process typically takes about 30 days, but all projects are different so take that statement with a grain of salt.

As soon as a Sprints backlog has been committed, no additional functionality can be included in the Sprint except by the team. Once it is completed and delivered, the product backlog is then analyzed and re-prioritized, if necessary, after which the next set of functionality is employed for another Sprint. This makes it easier to manage your product backlog. The overhead of the entire process is kept as minimal as possible in order to maximize the span of productive time available to get useful work done.

Scrum methodology has, for a number of reasons, been proven to scale up multiple teams across considerably large organizations with even more than 800 people. Its processes have enabled organizations to adjust fully and smoothly to the rapidly changing market requirements and produce products that meet the evolving goals in business. An agile Scrum process could benefit the organization in a number of ways:

•             Coping better with changes and expected evolutions in the field of business
•             Increasing the quality of available deliverables
•             Providing the project owner with more control on the schedule and its state
•             Providing better estimates while investing lesser time in coming up with them

That which distinguishes Scrum from other subsets of agile software development methodologies are the unique concepts and practices which are split into three categories: Artefacts, Time Boxes, and Roles.  Often Scrum is used in managing software and product development complexities. It increases productivity considerably and similarly reduces time to benefits relative to classic waterfall processes. (By the way, we'll be getting more specific about Artefacts, Time Boxes, and Roles in subsequent blogs).

Aside from the aforementioned benefits of the Scrum framework, there are other additional, more inherent advantages. Most importantly, Scrum provides a solid structure for the facilitation and promotion of team work. It can help the project manager to analyze the workmanship of the team or colleagues and potentially determining who is the most effective. The precise definition of roles allows managers to equitably distribute duties based on the skills of the developers without discrimination. And, this, ladies and gentlemen, makes Scrum a great option for any business that cares about output and performance.

Stop by next month when we delve more into the Roles aspect of Scrum - Agile software development. And, in the meantime, check out the services to see what our Nerdy teams can do for you!

What Makes Agile Software Development Better Than Waterfall?

http://mediashift.org/2014/01/the-j-school-scrum-bringing-agile-development-into-the-classroom/

One of the first decisions for every development project team is the ideal methodology to be employed in order to provide the desired result for the particular situation. This can often lead to debate.

Let’s back up for a second though to clarify what we mean by development methodology. It is essentially the process of organizing the work for a software development project. It does not necessarily involve the style of project management or a particular technical approach, but often these are interconnected.

So, back to our debate. Waterfall and Agile are the two popular frameworks often part of these discussions. Both are mature, usable methodologies, but Waterfall can best be termed a traditional approach, whereas Agile is a more specific type of Rapid Application Development (RAD), often implemented using Scrum. Scrum itself is a simple framework for team collaboration, providing an effective management and control structure for complex projects and reducing complexity, allowing the focus to be on building the software to meet client needs. And, actually, Agilists don’t call it a methodology, but more of a movement.

The Waterfall methodology uses a sequential design process and its workflow is much like manufacturing and construction processes. It has eight stages, each of which has to be satisfactorily completed before moving to the next.  This means that once the developers have completed one stage, there is no going back!  If problems arise, the only escape is ditching the entire project and starting anew. So, there really isn’t room for errors or change meaning that the project plan must be detailed, extensive, and carefully followed from the start in order to reach the desired outcome. There is stress on meticulous record keeping which does allow for the ability to make improvements in future if done properly.

In response to such a rigid framework and the perceived failure of the dominant software development project management paradigms like Waterfall, the so-called Agile Manifesto placed the emphasis more on collaboration and communication, team organization, and the flexibility to adapt. Agile software development relies on an iterative and incremental and adaptive approach. The methodology is open to the changing and encourages feedback from the end users of the product so that it also encourages accountability and consistent communication. Cross-functional teams will be able to work on iterations of a product within a specific range of time, ensuring that the end product is organized and prioritized on the basis of the customers or the business in general. Ultimately, with Agile methodologies, developers and clients work together in order to align the product with the goals and requirements.

So what makes Agile software development superior to Waterfall in our humble opinion? The concept of teamwork is often considered a powerful tool in the achievement of the goals for almost any organization. Extra Nerds, for example, works within a team paradigm and it is extremely effective. The team will vary, based on the project. The Agile movement creates a better platform on which decisions can be made by all parties at the table. It sources the efforts of both the developers and the stakeholders and combines them to form a unit that works for the greater good. Man is to err, and Waterfall methodologies make it really difficult to mend any broken bridges in software development. In contrast, Agile frameworks allow a window for changes, making it much easier to roll with the punches so to speak in the makeup of the system and to reduce redundancy.  Still, we are very flexible and some folks still prefer the rigidity of Waterfall et al. Regardless, the choice or recommendation of the software development methodology will be heavily weighted on the nature of the project. Once everyone has a clear analysis of the project, choosing the ideal framework shouldn’t be difficult.

Of course, this is just a basic overview, but there are many resources out there to learn more about Agile. You can also check out Extra Nerds to see what we can do for you and how we can manage your next project using any methodology - or movement -  you want!

Check back next month when we go more in depth about the core concepts of Agile, including Scrum.