Scrum Confessions – Part 2

In the second part of the confessions, I would like to talk about the scrum masters and the role itself. It is a difficult topic to approach, many companies and teams are very convinced of their love or hate for the masters they have or had. I personally also do not have any strong belief about the scrum muster function. I think the company culture, size and experience of the teams and the specific facts about the project are important to decide if and how scrum masters should be working with the agile teams.

I have experienced countless situations where the contribution and existence of scrum masters played the biggest role for achieving results. And I am not judging if the role is needed or not. My confession aims  to discuss about the difficulties and dilemmas related to the role that not many managers and agile coaches do not even mention about.

Confession 3:  Scrum master role might help or hurt companies and teams

88% of the scrum masters take on additional responsibilities beyond that of a scrum master. I think it is a natural outcome in many companies.  A self-organizing and gut performing team will be able to run the scrum process and minimize the need for coaching after a an initial peak phase of its teaming. Each organization has to consider the values, opportunities and risks of the scrum master role implementation that it has.

A scrum master who is supposed to act as a servant-team member or an agile couch can easily become a overshadowing figure who replaces the people manager in time or turns into a “master” in the team that gets all the air time with the senior management, tells the qualified engineers what to do, introducing rules and create an invisible authority on the qualified developers in the team. It is important to judge what personalities would match to the expectations for the role and make sure that the doers (developers) do not get frustrated, limited or exposed to pressure by this role. I have seen cases where developers underperformed or left to company because they were not extrovert enough to resist to such misplaced “masters” in their teams.

Another issue is the people management. Scrum masters in many organizations take on people management responsibilities, often without being qualified or without having the accountability. Many developers can spend months without talking to their direct people manager and they get regular “couching” from  “the master” who possibly does not have any engineering background or management experience to handle important issues regarding the developers’ career and development. Such situation creates an atmosphere of management attention vacuum for the developers. He loses contact to management, communication meetings and decision platforms while scrum masters run the show with middle management in the name of the sacred team. I have seen teams that enjoyed the sick leaves and vacation times of their scrum masters and performed better with this relief.

In case that it does not happen and the scrum master sticks to his role of making sure the scrum process in run correctly and remove impediments for the team, it takes no more than 2-3 years that a scrum master starts feeling underutilized, not challenged enough professionally and not recognized by his colleagues regarding his skills and potential. It becomes a management challenge to offer attractive career opportunities for these individuals within the technology departments.

Finally I would like to repeat how I appreciated working with many great scrum masters. The role and the implementation in the corporate world is not easy and it is time to discuss for the sake of the dev teams and the great masters to figure out how this function should evolve.

In the next part of the confessions I will continue talking about other scrum challanges like lifecycle management and architecture.

Scrum Confessions – Part 1

Agile development and scrum are no-brainer-choices in almost every IT department in Europe. Over the past 2-3 years it became almost a religion within the most tech communities, every executive and every proficient IT professional starts setting the scene by focusing the importance of applying the scrum process properly and effectively for success.

I do think that scrum has changed the way software is built ,  supported the development processes  in a very positive way and it opened a new era of engineering enabling the alignment of business and engineering much better than it used to be.  On the other hand, having gone through some scrum transitions in several working environments and based on my observations from the management balcony until now I know that there exist some typical and chronic problems around scrum that bother the most of the stakeholders.

Now, I don’t mean the problems that are  related to the suboptimal implementation of the scrum process or not understanding the philosophy. Indeed, probably the first thing  you would hear when your project fails, delivers late or actually gets way to expensive to finance would be: “there must be something wrong with your people and the way there are doing scrum”. However, I believe ,scrum process and roles have weak points and fundamental issues causing productivity and quality disadvantages.
I think many executives and computer scientists working with scrum do know that it cannot be efficiency or the people every time.  We know this funny feeling that there might indeed be some stuff fishy and not mature about the beautiful scrum methodology. Somehow, we usually prefer not to talk about these thoughts and experiences. It is an unwritten law not to question the process and always praise the practices thought to us by the gurus of the Scrumentalists. So I decided to write a series of blog articles which will reflect my observations and criticism about scrum framework, its deficits and risks that every IT manager should consider.

Confession 1 : The product owner will always fail

We expect product owners to act like product managers and drive the business while being fully aware of the customer expectations and competitive market out there. Easy said than done, this means that a PO needs to have strong external orientation, time and skills to drive the KPIs and strategic decisions related to the product. They are also need to have project management skills and fully control the product backlog and prioritize tasks for the team, write the stories and be responsible for translating end user requirements in a way that the team can understand and correctly implement. She has to judge operational and emergency issues against new feature development and act as a leader to keep everybody focused and energized. Which actually requires that she has to be technically  quite knowledgable  about the software development technologies, be internally oriented, have at least some engineering skills and do lots of things that is outside the scope of product management or business analysis functions of waterfall days.

There is hardly anyone on earth who can juggle so many balls in so many disciplines. The consequences of such illusional expectations for the companies are really serious and it is a huge problem for many executives. Because we want convincing market analysis about the products we decide to invest in, see the KPIs and reports that enable us to measure success and of course(!) there must be somebody who is accountable for the optimal delivery of new features while fixing the right bugs and giving the necessary support for operations. The bill is mostly charged to the product owner in cases of failure or problems. “There must be something wrong with her” or “we need to improve how the role is defined and understood” or “ it is a product owner who did not understand/do this and that” bla bla bla. It is an endless and useless conversation! I have known many POs with extraordinary skills and amazing performance but the PO defined above does not and will not exist.

So what could be a solution? : Personally I believe mid and large size companies need to separate the business and technical process side of the product management and install a separate set of professionals who are accountable for the product KPIs, market competitiveness, benchmarking and external analysis of opportunities and risks for the business. These people do not have to cuddle with the scrum team on a daily basis and they do not need to know all the user stories and technical details about the product. Call them product managers, business analysts or anything you want. POs on the other hand can focus on the internal and more technical aspects of software development and backlog management; they get the product delivered fulfilling the defined KPIs by her partner with the help of her team.

Confession 2:  Scrum=software and processes without documentation & lots of risks

Agile manifesto says “we value working software over documentation”. What happens in reality is that over 90% of all scrum projects are not or very poorly documented. There is no incentive, recognition, rules or any process for documentation in the framework. What is even worse is that the framework turns developers into professionals who do not value documentation and find the related tasks boring and inferior. And it hurts, it hurts you a lot

  • When you have attrition in your core team and lose the valuable know-how
  • When your services team have no documented and structured data about what peculiarities and operational requirements a new piece of software on production has
  • When a developer needs to maintain the code he has not implemented and it costs way too much for the company
  • When you need an overview of your services or product value chain and you don’t know what processes are mapped to your running software in what way. (This will bother you a lot in case of ERP,SOX or CMMI implementations, mergers, attempts to scale the business)

There have been discussions in the communities about the need of a technical writer in the scrum teams to tackle this problem. My reaction to this as a manager would be “what???!!”. Seriously I don’t get why managers have to be satisfied with the output of what scrum delivers to them and find additional ways of obtaining the product attributes they require for their business.

Management does not have to care what possibilities scrum has. It needs product with proper functionality, the required user manuals and documentation for internal operations, it is part of the order and it needs to come in the package. Instead, a manager will likely to hear comments like “if you need documentation that will decrease out velocity”, “ you have to invest more into this project, much much more” “ we have higher priorities than this” or “it is not part of feature development of our scrum process” from the team.

I believe ,again the problem is not about management’s understanding or the teams. Scrum fails to provide the practices and incentives for defining and delivering the documentation with the required amount of detail and quality to an enterprise. It needs to be tackled and implemented in each environment and become a mandatory part of the software engineering process.(If you think you can commit such a sinn against the scrum religion)

Coming up next soon : Scrum Confessions – Part 2 with issues about scrum master role, software architecture problems and application lifecycle challenges..

Some Thoughts On Testers And Testing Teams

Recently I heard the dilemma of being a tester from a friend: “If you find many bugs and quality flaws , the developers hate you. If you don’t find them you are anyhow useless….”  There must be surely truth to it. It has been a known and old issue for many testing departments not to have the same visibility and recognition as developers within their organization and their projects.

Agile practices brought also many additional questions and challenges to software quality management field in the last years. There has been many discussions questioning the future of testers and QA departments.  It is mainly due to the blurring boundaries between old fashioned roles. The days of DBA, sysadmin, developer and tester siloes are gone, there are various success stories of companies that eliminated the matrix structures and clear scoping of the engineer tasks : “Facebook has no testers..”, “ XYZ Company is doing dev-ops and people have full access to everything”…

Yet the need for teams and individuals who are skilled to perform various complex tasks and willing to be accountable for the quality of the outcome is bigger than ever. Today’s successful teams consist of engineers who are continuously developing their technical mastery and are able to apply the systems thinking to their work at the same time.

So what do you need and do not need as an IT manager? The question is actually not whether you need tests or not. The question is also not whether there should be dedicated engineers who master in testing techniques. The main question should be whether you need a separate testing team or discipline within a certain environment. It is of course possible to produce high quality software without a testing team in many scenarios. However, in many other cases the optimal software development and ALM processes can only be implemented through a separate testing team. There is no one-size-fits-all solution.  Every company, every development organization needs to find its own unique setup for success.

How do you decide?  First of all, take a look at the behaviors and competencies of the engineers you have in the team. And decide which efficiency and what level of testing excellence is required for your product.  Good testers are quality specialists and offer unique advantages to the QA process. They work and think differently than the rest of the engineer team. They are trained to find and report problems.  Naturally, an experienced testing engineer would very likely to have the techniques, personality and experience to find, report and present bugs faster, better and more effective than most of the other development engineers. If you go for a solution with a testing team, you need to make sure that they are more than bug documenters or quality advisors. They need to have certain authority and decision making power over certain project execution situations, spring breakers and change management.  Here the key is that the testers and their lead understand the business priorities, defined quality metrics and the stakeholder needs in the whole system so that they can find the right balance of business needs and risks. Making the right call to fix or backlog a bug, escalating an emergency to halt a sprint, getting other decision makers’ buy-in in various critical situations are vital skills for testing professionals. So if you decide for a tester team, get good people on board, empower them and support them get the credibility and trust from their peers and cross-functional teams.

If your decision is go for a one-team approach without a testing team, make the quality metrics top priority for everybody and hold certain individuals accountable in the scrum teams. Ensure that the product owner is also held accountable for overall quality of the outcome. Train your engineers to know/understand how critical each error is and what types of errors should be avoided, develop strategies and integrate in to the development process. A developer is focused to do things right and get the code out whereas the testing-mode requires to look at the “bad” in the system in a systematical way,  to focus on to find out what is wrong and be determined to break the system.  It is a conflict for a developer to try to write solid, quality code and to fearlessly attempt to break and take things apart almost in a destructive way while testing. Give your teams opportunities to practice and reflect on different modes of working in a software project; improve the approach with their feedback after each sprint if necessary.

No matter what your decision is, best practices and agreed processes may help you to find your way to plan and get your software out with the desired quality. And you have to invest a lot of energy and priority in automation: do not end any meeting or project regarding testing without having talked about the status of test automation efforts. But at the end of the day, the main impact on the quality of the software does not originate from processes or methods. What matters by far the most is your people, the team, what capabilities they have and how they work together. The development and testing leads should motivate the engineers and get their commitment for quality by clear messaging about the importance of quality, impact of testing to the project and the company.  Track and recognize the engineers’ contributions within the community, make sure you have their support for the project and there is always someone to ask for help and to discuss about issues/problems.

Quality must be everybody’s business involved in the whole value chain starting from user request to the end of life of the software. And in many organizations there is a separate testing and QA team to drive and support the quality management discipline in a professional manner. But the bottom-line is that every team member, every manager and developer carries the responsibility of the quality of the product they ship, with all its success and other consequences. If this awareness and corresponding culture can be created, it would be much easier to get the support and creativity to find the processes and organizational setup that work for your teams.

Recommended reading :

Beatiful Testing, Does the existence of seperate QA Team damage quality?, end of the tester, Systems Thinking

%d bloggers like this: