Wednesday, April 11, 2018

The Manager Role in Scrum Team | Supreme Agile

The scrum framework contains three mandatory roles that co-exist as scrum team, Development team, Scrum Master and Product owner (The general direction for the rest of the stakeholders such as management, architects Etc. is to support the team).

Because of this definition, we can now understand why the same question arises in almost any organization that is trying to make a transition to Scrum. “Where is the definition of team leader in scrum?”  Alternatively “Is there a necessity to keep them?” By asking these questions, we can understand that the organization is in the first phase of exploring scrum and what does it really means to implement it.  

If you are familiar with the Scrum framework, you are most probably aware that scrum teams are structurally different from traditional development teams.

In most cases, the traditional teams will follow a “Top-Down” approach where Management defines the project deliverables, schedule, and pace. While on the other hand, scrum teams will utilize a “Bottom-Up” approach, where they will determine their own pace and deliverables based on prioritization, Velocity, and capacity of the team (Under the restrictions of the organization boundaries of costs, Budget, declines etc. ).

The traditional role of a manager in the corporate world

The traditional role of a manager based on a well-known method of “Command and Control”. This method based on one single authority (Manager) that will control the major aspects of the project such as Team deliverables, Processes Schedules, and budget.

In this method the interaction between the manager and the employees is based on four simple phases:
  1. The Manager will identify the organizational “Needs” that based on budget, commitments and pre-defined plan.
  2. The Manager will provide to his employee a list of detailed instructions of demands, expectations, and goals (The employee should follow the instructions trusting the experience, judgment, and knowledge of the manager).
  3. The Manager will monitor the employee progress that based on specific instructions.
  4. The Manager will compare the employee deliverables based on the preliminary goals.
In the constantly changing software industry, this approach becomes less efficient and by far less productive than what we have in agile frameworks. There are many reasons that can explain this and why more and more organizations are now moving to agile. To clarify my point, I will focus on these three aspects:

Productivity – There is no way that a single manager can handle the current challenges that arise in almost any software development project (At least not in an effective way). Just think about the areas that this manager will have to handle in a single project starting from Understanding the organizational and technical requirements, Scheduling, Deliverables, and Quality.  

Centralized Management – We cannot throw this method just because we now have an alternative, but let us face it; centralized management comes with some major challenges starting from the need to issue list of technical instructions to the team (sometimes per employee), Handling internal/External dependencies and continuing with dealing with HR issues that may critically affect team performance.

Team Motivation – I think that we can all agree that this type of management (Depending on the manager and his leadership style) will not help to increase employee motivation. As followers, the employee role is to follow their manager instructions with the absence of freedom, decision making and trust that will not provide any sense of real ownership of their work.

Why agile can be scary for some managers? 

Prior to diving into the manager role in Scrum, I want to add more information about the “Bottom-Up” approach that used in Scrum. Scrum uses a more advanced approach to creating “Self-Organized, Cross-Functional” teams that can take full ownership of their work. This ownership is reflected in many aspects that were once fully managed by a single manager (described in the previous section) such as; determining the amount of work to deliver per iteration, Collective ownership of their work, Self-Management and the ability to decide how and who will perform which task to take. 

Now, as I mentioned at the beginning of this article, the Scrum Framework contains three main roles (Team, SM, and PO) that are critical to the success of the project. However, the Scrum Framework does not provide the same level of details regarding other main stakeholders that we expect to see in any SDLC project such as; Development manager, Project manager, product manager test manager or any other stakeholder that possess a management role.  

Therefore, those stakeholders who are involved in agile transition will struggle to find their role in the new agile teams. Especially when there are no criteria that specify their new responsibilities.  

The role of Managers in scrum team

In theory and based on my own interpretation of the Scrum Framework, the role of a manager in Scrum can be summarized as follows:

Re-Organization – I think that it is a classic for managers to help the organization to make the transition from a traditional way of working to scrum. Their work will focus on the “Re-Organization” and in the removal of any barriers that may affect this transition.

Servant leader – Similar to the role of the SM, managers should shift their state of mind from a single authority into servant leaders of their teams. Their new activities will focus on many aspects that will help their teams such as; creation of safe working environments to their teams, investigating for new tools that can improve efficiency and plan technical training that will improve areas where the team's skills could be improved.

Not interfere – It is simple, to allow Scrum teams to grow, the old fashion management must be removed and the team manager should take one-step back and not interfere with the Scrum implementation (It is a critical point for new teams that just started with scrum).

Change Agents  The organization TL’s should allow the organization to get the most from Agile, One way to achieve this, is to embrace the new agenda and state of mind that comes as mandatory part from this approach and to grow with it to help the organization to achieve better results.

Lead by Example – This is probably one of the most important keys to an Agile transition. Leaders that used to lead by “Authority” now must embrace the new culture and start to lead by “Example”. This is while at the same time allowing their teams to grow and take further ownership.  

Removing organizational Impediments – like we expect from the team Scrum Master to remove impediments that affecting their team capability to perform at the highest level, we can expect the same from the organizational TL’s to do the same. They need to reinforce the team with relevant resources, remove bureaucracy, and provide training as needed.

Feedback – Constructive feedback is another tool that managers can use to promote their agenda in their teams without enforcing it with authority as they used to do in the traditional style of management. Constructive feedback will assist the team to improve continuously.

Technical Assistance - Managers can use their knowledge, experience, and expertise to provide assistance whenever the team needs or ask for it.

Determine prioritization – This is a classic area for these managers to show their importance to their teams and especially in the process.  Using their knowledge, experience and broad perspective, they can allow the team to make a robust and more effective prioritization to increase their ROI.

Classic examples:
  • Assist team to prioritize technical debt affecting their ability to deliver real value. 
  • Assist team with the iteration planning and prioritization of their stories.
  • Assist Product Owner to prioritize the product backlog
  • Assist Product Owner and team to achieve the balance between “Functional” and “Non-Functional” stories.

Drop Their Ego – To be able to take part in the agile transition, managers will have to drop their ego and learn Agile from their Scrum Masters. Now’ it is easy to say it, but I have seen too many managers that fail to drop their ego and learn from someone that was under their direct management. This leads usually to unwanted results. 

Human Resources – Well, this aspect is still under the management responsibility. As part of his job, the TL will conduct regular 1:1 meetings with team members and provide assistance with different HR issues. In addition, they will recruit and hire new employees, integrate them into the team (With the collaboration of the SM) and remove any negative effect that may arise while integrates a new employee into the team.

The traditional manager as the new scrum master

A common approach to redefining the role of the traditional manager is to convert them into the new Scrum Masters of their old team. On the face of it, this seems to be good for the company, but believe me that it can be devastated for the team. When the manager plays the role of the SM, it is very unlikely that the team will gain a true confidence to begin to self-organize itself. The manager will most likely keep the hold management patterns and old habits that will make it almost impossible for him to release ownership to team members (an Agile fundamental concept).

Now, I have seen many team managers successfully transition, this is because they strongly believe in their team and in the Agile values. However, I always believe that the Scrum Master must be chosen and agreed by the team members and therefore should be one of them and not their old manager. 

Wrong Practices to avoid

Let us review some of the most common incorrect practices that I have seen in organizations in relation to this topic.

Assign the work for the team – one of the major cornerstones in Scrum, it the creation of “self-organized” teams that can determine for themselves the team member who will take ownership of the specific unit of work. Therefore, there is no need for using old management habits of assigning the work to the team.

Ensure work is completed – The team is responsible, therefore they need to follow the “Definition of Done” and “Acceptance” criteria.

Monitor what team members are doing – This responsibility belongs to the team, they need to provide answers during their daily scrum meeting. 

Work with your ego – Team leaders who fail to drop their ego and do not listen to their teams will become the team most critical impediment.

Prioritize the work – The team together with the product owner own the work. Therefore, the TL can assist and share his thoughts. He must not have the authority to delegate or priorities the work items. 

Decide what work needs to be delivered – It’s simple, the scrum framework provides two roles that are responsible to this issue, the PO that determines the features and requirements that need to be delivered and the development team that determines which tasks are necessary to achieve it.

Micro Management – I think that if you went this far in reading this article you have gained the knowledge to understand that Micro Management and Scrum are not linked to each other. 

Wednesday, March 28, 2018

The courage to work under Uncertainty in Scrum teams | Supreme Agile

To become fully agile, the team must leave behind much of their traditional project management mindset. Traditional project management can have many aspects that are not relevant to the values and principles that come with agile adoption. This is especially true in allowing a team to make mistakes as part of their growth engine.

Due to the nature of Traditional project management, wrong estimations delivered by the team can lead to dangerous consequences that will affect the entire organization and especially on team morale.

Once the organization decides to adopt the Agile framework, they must allow their Scrum teams to work with high level of uncertainty and keep moving forward no matter if they provide wrong estimations about their ability to deliver their commitments (Measurements, Training, and processes need to be put into place for this to work, This is a complete culture change).

The level of Uncertainty

We all know that for the team it will be simpler (That have some experience) to provide more accurate estimations when using Agile. This does not mean the estimation problem has been resolved. Time estimations can be wrong in agile as much as they are when using traditional SDLC methodologies.

The main difference in agile is that we can accept the idea that the development team can be wrong with their estimations and this is even more true with new teams that have begun following the agile framework. The assumption that Agile will resolve this problem is wrong (although it can improve it dramatically). This is because although the level of uncertainty is lower, it still exists. One cannot assume that the team will be able to provide accurate estimations, good task breakdown during the planning meeting. This is especially true during the in the beginning. 

Embracing courage as a growth engine

There are two main approaches to handle estimations mistakes. The first option is more common in traditional project management methodologies. This method is to point the finger and blame the development team regarding their mistakes and its effect the project.

This approach is what I like to call an "HR" killer that will neither contribute to the motivation and commitment of the team. Blaming is not an effective method to encourage people to improve their abilities. The only output will be that next time, the team members will provide exaggerated estimations just because of they afraid to be mistaken again. 

In Agile, there is a more acceptable room for mistakes that come from the overall mindset that mistakes can be used as a great method for the team to grow, especially when the team reviews them in dedicated retrospectives. Remember that for a team member, It takes courage to stand in front the rest of the team and say "I got it all wrong" or "I made a mistake that kept us from completing the story", but it will allow him to get the help of its team and the confidence that they will help him to improve next time.

Being Agile instead of doing agile

Once the organization decides to start the transition to Agile, there will be a period of weeks and even months that the old project management style will still be the dominant one (do not think otherwise…). This will continue until the organization change its culture and really adopts the agile values and principles.

During this hard period, the Scrum Master is responsible to provide the team with a confident working environment that will allow them the transitioning to "Being" Agile. This is completely different from just "Doing" agile.

In order for this transition to be as smooth as possible, the Scrum Master on one side must remove pressure and any external interruptions that may affect the team. While on the other side, he must recognize warning signs that come from the team itself. This demands more HR-related skills that will enable him to become effective discovering problems earlier.

In tradition project management, often there are slow, ineffective meeting that is usually as the result of missing direction/deadlines that came from a single authority. However, in agile slow and ineffective meetings can be the result of lack of courage or poor team commitment.   

A good experienced Scrum Master will know each of the Agile activities has its own warning signs. From my point of view, daily standup and the retrospective meetings are the best places to see them.


No courage to admit lack of knowledge

The first example related to these meetings is a team member that does not share any obstacles or impediments. These can result in either slowing down work or dangerous/blockages scenarios that could occur. Both these can result in a delay in meeting time schedules.

A good Scrum Master must see warning signs and should proactively seek to understand the reasons for no progress but determine why no impediments have been reported.

Once the Scrum Master recognizes this issue, he needs to understand the root cause of why the real problem is not reported by the team member. Based on my own experience, a short discussion with this member will reveal that he was not confident enough to stand in front the rest of the team and ask their help. This often results in the team member trying to provide a fast fix to the problem. This takes time. This can have an impact on other team members and result in them losing trust in the team member or the group or Agile process. 

Time Estimations 

Another classic example relates to time estimations that the team needs to provide for tasks during the planning meeting. A clear warning the SM must look for is once team members say that they cannot provide estimations because they do not have enough information about the task. This may be ok in some situations, but based on my own experience the root cause is that the team members do not have the courage to admit that he just doesn't have what it takes to complete what the PO asking for (Or they don’t understand the requirement and what is expected from them…).  

Once this occurs, it is the Scrum Master task to explain to the team it's ok to make mistakes. It will assist them to improve their next planning meeting. Within the Agile framework, there is room for this. Therefore, team members should not be afraid to request assistance from their team members or that they need more information that will help them to handle the task. 

The Scrum Master should consistently remind the team that it takes courage to take an educated guess (Every estimation is a guess unless you have a crystal ball that can show the future). The unknowing on how to finish the task does not say that you cannot start working on it and deal with future problems once they occur.  

And as the Scrum Master

If you are the Scrum Master of the team, it is your responsibility to search for warning signs. Although I provide just two examples there are many more warning signs that can help you to determine how courageous your team really is while providing their estimations.

Based on the warning signs revealed by your team, it’s your responsibility to coach your team on how to be more courageous and transparent to allow them to keep moving forward without rather their estimations are correct or not (I can assure you that it will improve per iteration).  

Sunday, March 18, 2018

Scrum Master - The Questions to ask | Supreme Agile

A truly great professional Scrum Master can make the difference in the creation of any successful Scrum team. I have written many articles about the SM role, including the responsibilities, characteristics, and checklists that can help to any professional. One thing that I still haven’t published is some of the key questions that a scrum master should ask to promote the process of continues improvement and most importantly to implement the agile mindset. 

Product Owner (PO)

תוצאת תמונה עבור ‪product owner‬‏
  • Does the product owner get the information from the team about newly added stories?
  • What are the expectations from the team when adding "Non-Functional" stories?
  • How do you handle changed requirements and how do you reflect it to the team? 
  • Does the product owner need help to create the functional stories?
  • Does the product owner have clear and direct access to the team?
  • Does the product owner understand the non-functional stories? 
  • Does the product owner understand the purpose of each item? 
  • Can the product owner explain the product vision?
  • Does the product owner have a product roadmap?
  • Does the product owner committed to the team?
  • Does the product owner have the knowledge and experience to prioritize the product backlog?

Scrum Events

תוצאת תמונה עבור ‪Scrum ceremonies‬‏
  • Are there any major delays or absences that can reflect major problems?
  • Do team members come prepared to these meetings?
  • Do the meetings start and end at the scheduled time?
  • Do all meetings meets the preliminary set time-box?
  • Do all mandatory stakeholders attend the meeting?  
  • Is there a clear goal and Agenda? 

Product Backlog

תמונה קשורה
  • What is the amount of stories that modified after they originally written? 
  • Is there an Acceptance criteria defined per each product backlog story?
  • Does the product backlog contain stories that can fit a single iteration?
  • Is there user stories that are not relevant and should be removed? 
  • Is the product backlog prioritized (Top Items at the top of the list)?
  • Are the product backlog stories have Definition of Ready (DoR)?
  • Are the product backlog stories have Definition of Done (DoD)?
  • Does the product backlog contain stories that are informative?
  • What factors are used as part of the prioritization process?  
  • Does the product backlog contain stories that add value?
  • Is the product backlog transparent all stakeholders?
  • Is the product backlog visible to all stakeholders?
  • Are top items estimated (Rough Estimation)?
  • Is the product backlog consistently updated?
  • How large the product backlog really is?
  • Does the product backlog contain the "Non-Functional" stories that requested by the development team? 
  • Is there an agreed form between the PO and the team on how write and Add stories to the product backlog?
  • Is the product backlog exceeds a reasonable threshold  (Usually stories that are available for the 3-5 iterations)? 

Sprint Backlog

תוצאת תמונה עבור ‪Sprint backlog‬‏
  • Does the sprint backlog contain stories agreed by the team?
  • Does the sprint backlog contain stories with relevant tasks?
  • Is the sprint backlog visible to all stakeholders?
  • Does the sprint backlog stories are estimated?
  • Is the sprint backlog owned by the team?
  • Is the sprint backlog update daily? 

Daily Scrum

תוצאת תמונה עבור ‪Daily Scrum‬‏
  • Are there follow-ups for any issues that were not addressed during the meeting?
  • Is the meeting occurring without active promotion by the scrum master?
  • Are there any technical discussions that encounter the meeting agenda?
  • Is there a follow-up for technical issues that arise during the meeting?
  • Is the meeting is occurring at the same time and at the same location?
  • Are team members reporting impediments that affect their progress?
  • Does the team conduct a meeting when the SM is not present?
  • Is the "Burn-Down" chart updated at the end of the meeting?
  • Are there any external interruptions during the meeting?
  • Is the sprint backlog reflect the work for the next 24H?
  • Are there any "Reporting" symptoms to one authority?
  • Are all team members participating in the meetings?
  • Is there any discussion about the iteration goal?
  • Does the meeting occur in a safe environment?
  • Do all team members share their insights?
  • Is the team focused on the iteration goal?
  • Do all team members come prepared?
  • Is the team progressing as they forecasted (are there any risks identified to prevent meeting the iteration goal)?

Refinement (Grooming) Meeting

תוצאת תמונה עבור ‪backlog grooming meeting‬‏ 

  • Are all stories small enough so they can be completed within a single iteration?
  • Are there any team members want to take an active role in this meeting? 
  • What is the average amount of stories that refrained per session? 
  • How effective this meeting for the product owner and the team? 
  • How much does it take to approve the readiness of a user story? 
  • Are all changes made by the PO communicated to the team? 
  • Is there any open issue that should be addressed to the PO?
  • Is there any open issue that should be clarified by the PO?
  • Is the PO can explain stories from a business perspective?
  • Do you involve the team during the refinement sessions?
  • Do all Stories have the mandatory information? 
  • How often the team performs this meeting (Should be at least once a week and even more for new teams)?

Review (Demo) Meeting

תוצאת תמונה עבור ‪scrum demo meeting‬‏
  • Does team members come prepared with a working example of their work?
  • Are all presented stories meet the preliminary "Definition of Done"?
  • Is there a room with the relevant hardware to support the meeting? 
  • Is the product backlog updated based on the feedback? 
  • Does the team have the information (Metrics, KPI's, Impediments Etc.) that can increase the transparency between the team and stakeholders? 
  • Does the meeting occur at the end of each iteration?
  • Does the team demonstrate only completed stories?
  • Is constructive feedback provided by the PO?

Sprint Planning

תמונה קשורה
  • Do all candidate stories have all the relevant information (Acceptance, DoD, and DoR)?
  • Are all the stories explained and understood by the team prior to the estimation process?
  • Are there any experts that need to participate to help the team with their estimations?
  • Is there collaboration between the PO and the team regarding the iteration goal?
  • Is there a calculated velocity for the team (SM Responsibility to calculate it)?
  • Are all team members agreed to take the commitments for the next iteration?
  • Is the team took commitments to more work than they can deliver?
  • Is there an agreement between the team regarding the work effort?
  • Is the estimation process efficient to predict the real work effort? 
  • Is the product owner happy with the expected deliverables?
  • Can the team answer what is included in the iteration goal?
  • Are all team members committed to the next iteration? 
  • Did the entire scrum team attend the planning session? 
  • Are all questions answered by the product owner?

Retrospective Meeting

תמונה קשורה
  • Decide with the team if they want to invite any external stakeholder that can contribute to the meeting (Very rear but sometimes can help the team to increase their insights)?
  • Decide with the team if they want to invite the product owner to the meeting?
  • Is the impediments board updated at the end of the meeting?
  • Does the retrospective occur at the end of each iteration?
  • Is there real continues improvement from the last retro?
  • Is the retrospective occurring in a safe environment?
  • Is there real collaboration between team members?
  • What is the focus of the upcoming retrospective? 
  • Is there a real process for impediments removal?
  • What impediments are more urgent to resolve?
  • Is the meeting owned by the team?

Team Velocity 

תוצאת תמונה עבור ‪scrum team Velocity‬‏

  • How team velocity can be used as a leverage to increase team motivation?
  • What is the unit used to measure velocity(Hours, Days or story points)?
  • What activities that made during the sprint included in velocity?
  • Is the team velocity used to determine the team commitments?
  • Is the team velocity reflect the true capabilities of the team?
  • What is the trend of the team velocity (Positive/Negative)?
  • Is team velocity transparent to the relevant stakeholders?
  • What is the module that is used to calculate velocity?
  • What can be done to improve team velocity? 
  • What is the average team velocity?

Questions to ask the Development team

תמונה קשורה
  • Do we all agree with the quality of the PBI as they currently written by the PO?
  • What is the team expectations from the project and what they hope to achieve?
  • Is there anything that we can do to improve the precision of our estimations?
  • Do they agree with the DoD of the stories and can they achieve them?
  • How should we handle internal conflicts that arise during the project?
  • What are the Key factors that will help us to meet the project goals?
  • How should we celebrate success in achieving the iteration goal?
  • Is there any team member who is disrupted by external forces?
  • What should we do if we do not succeed to meet our goals? 
  • What obstacles do we have as a team to achieve our goals? 
  • Are there any personal issues that affect team members?
  • What dependencies do we have with other teams? 
  • What is our velocity? How can we improve it?
  • Is there an improvement in the agile mindset?
  • Are they agree with the DoR set for stories?
  • Is the team show progress in their velocity?
  • What is our preferred estimation technique (Relative Vs Absolute) to estimate the stories during the planning meeting?
  • What is the team CI (Continuous Improvement) that we want to achieve at the end of the project?

My Presentations