I arrive to work at 9:00. The first thing I do is go to the cafeteria, get my coffee, chat with my colleagues and manager since most of them are present there around same time. After that I go to my desk, outline the work I am going to do today so I have something to present at our team’s daily, 15 minute stand up meeting,.
Stand up meetings are extremely important to Agile projects. Face to face interaction between all involved in the project is key to knowing what everyone has completed, what they plan to work on that day and what challenges they are working through. I know what Ken, Adam, Sara, Ali, Mark and Anita are working on, also I know what kind of problem each of them are facing through my daily standup meeting (15 minute meeting happen every morning). In stand-up meeting we all describe what we are working on today, what we worked on yesterday and what kind of issues we are facing to accomplish our task on time. After the meeting, I start working on the task I chose to work on during stand up meeting.
Our whole team including a manager sits in one room, we sit facing each other and talk to each other when ever need to (Face to Face communication). That also makes communication extremely easy and simple. In such an environment, team members learn from the indirect communication that takes place in the area without directly taking part in the discussion, Cockburn calls it Osmotic communication.
We also reference the board area; board area contains visual representations of the projects progress, risks and risk severity level. Visual representations contained in this is area include agile boards (scrum board, release board, risk board and retrospective board) and information radiators (burn-down, burn up graphs, velocity, tasks dedicated, % completion of sprint and releases etc.) These resources ensure every member of the team is aware of the progress being made towards completion of tasks and overall project.
Our development cycles, called sprints, repeat every two weeks. Before every sprint we hold Sprint planning meetings which are attended by the whole team before every sprint. A key sprint planning meeting attendee is Adam, the project owner. He is responsible for creating requirements (user stories) and prioritizing them, based on his business knowledge and discussions he has with other team members. Adam is a good listener, and has immense business knowledge. He is also available for any questions our team may have regarding the requirements.. Adam writes requirements and places in a repository called a backlog. Each requirement in the backlog is called a User Story. Adam also set the priority of the user stories in the backlog, that priority changes based on the discussion takes place between project owner and team during sprint planning sessions.
Our manager respects our opinion and encourages us when we disagree with him or someone else in the team, as long as we do it in respectful manner. In other words we are an empowered team. Also we select our work ourselves and collectively estimate the task and amount of time needed to complete those tasks, that liberty make us a self-driven team. During the planning meeting each user story is estimated and prioritized, in this process teams input plays a vital role. Adam changes the priority and estimation of the user stories in the backlog based on our team’s input.
I take help from Ken, Sara, Ali or Anita whenever needed or sometimes our manager asks us to help each other especially when we face a critical issue which could hinder the progress of whole project; a show stopper. If as a team we cannot solve an issue, we escalate it to Mark, the scrum master of our team. Mark is very affable and an approachable person, who keep us aware of the progress we are making. He is available and strives to remove any issues we have; technical or non-technical. He also makes sure that all the information radiators are up to date and meetings are being convened in time. He performs the role of facilitator and a leader at the same time, in other words he is a servant leader.
Adam, the project owner, is present in all the planning meetings including daily stand-up meetings which keep him aware of the progress of the sprint and release. He is subject matter expert and talks to the customer (Kevin) on the daily basis. Occasionally, Kevin visits us and sits in our meetings. After every sprint team gives a demo of the product to Kevin and the team. That meeting and demo is called Sprint Review meeting. We welcome everyone to attend Sprint review meetings. It is a good time to get feedback on the product. Also Adam makes sure that the customers (Kevin and his team) understand what we are building and why we are building certain feature before others.
At the end of every sprint (after 2 weeks), we have another meeting called Sprint retrospective meeting within the team. Kevin (Customer Representative) usually does not attend sprint retrospective meeting. In this particular meeting we discuss the processes we followed during the sprint. We point out what went really well and what did not go as good as we planned. Mark (scrum master) makes changes to the process followed during the sprint based on feedback given during the meeting. Changes to project processes include changes in communication, project velocity, and architecture design or any other practice or process. The number of tasks completed in a sprint by the team is called velocity of the sprint. It’s measured in ideal hours or Story Points.
We deliver or “release” the product to customer after every six sprints. At release level we prefer to provide customer working software. Adam, the project owner, takes care of the User Stories at release level as well. He manages the release level backlog and selects user stories to be completed from Project backlog and moves them to release backlog. Release related planning is performed in release planning meetings. In summary, Adam manages three types of backlogs, project backlog, release backlog and sprint backlog.
Sometimes we still have a few stories left in the backlog at the end of the project. The reason is that we try to complete those requirements which add most value to the customer. Some of the features might not add that much value to the customer in the allocated project time so those requirements are not implemented in that project.
Author: Mobeen Siddiqui, Provides Agile coaching services in Minnesota, particularly in greater Minneapolis area.