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..

About The Human Factor In IT Services

Services is a very broad sector, it can be basically defined as everything produced except manufacturing and farming. IT services is one of the most complex and biggest subsets of the industry. Defining meaningful categories , standards and controls is pretty difficult given the diversity of the services being offered and the factors influencing them.

So what is the most challenging parameter in the services equations? It is the human factor. In no other industry in the world, the human is so important and critical for the effectiveness and efficiency of the business. No other industry depends so much on the people’s education, experience and behaviour (and ethics). This fact can be a blessing or a curse for a services organization; performance evaluation and management is much more difficult than any manufacturing sector. You can never standardize and have a control on the output as you do with processes and machines, the same “input” will not always produce the same results with services delivered by humans, your business will always have higher variability of  risks.

If the conditions or the environment of the human changes, the criteria for evaluation and success will change too.Hence the service organization goals defined are also subject to change at all times, leading to more uncertainty. I personally think that the longest time horizon that can realistically be set and controlled in IT services is  around 1 year, for greater enterprises maybe some more. Any objective defined for 3 or more years in advance makes as much sense as predicting the weather for that point in the future.

For the purchaser, the huge scope of services and the dependencies on the human skills and capabilities increase the risk of the services spending in many ways. How can they assess the value and quality of the services being delivered? Standardization and quality control may be difficult or not feasible at all. The diversity and dynamic nature of the sector usually require the customization of the service to fit to the exact needs of the purchasing company;  a standardized approach is not always the right call for the receivers of the service. Besides, it is usually not the purchasing department that can determine if the service was carried out properly. And one needs to purchase a certain type of service at least once to make a solid evaluation of the buying decision.

The services company has the responsibility to consider all the intangible and human related factors as well as the challenges of its customers (i.e purcahser) to  reach and maintain a sustainable success it its industry. Given the high level of risk and uncertainty for both sides, the most important task is ensuring that the all the relevant information is communicated efficiently, especially when it comes to the requirements, the service cost and bidirectional feedback. Another vital task is the management of the skills and capabilities of the organisation and each individual involved. Investment in the processes, assets,staff and synergies is the “only” way to differentiate a service organisation from the others.

Even the investments are made and an optimal portfolio of skills  is built, services organisations are exposed to risks of uncertainties and intangibility. The management of these risks should be done via demand management. One cannot create an inventory of services to serve the customers in times of higher demand. There is always an uncertainity that the demand may be below or above the existing capacity. (and it is usually so). Demand can experience a huge change overnight whereas building services capacity with skilled human labor is a time-consuming and expensive investment. Meeting and creating the demand is the key to survival in services. But how? Well, if I knew the exact answer, I would probably be an entrepreneur now. 🙂 On the other hand, it is for sure very important to build a good CRM system to understand the chaninging needs and behaviours of customers, build a relationship based on trust and opennes. Use of IT frameworks and service delivery methods also helps both the purchaser and the service provider to agree on expectations and be able to fix short to mid term plans. For instance; SLAs, integration of frameworks like ITIL or MOF, ability to comply to SOX or TQM requirements make life easier to manage scope and quality in this huge heterogenous landscape.

Services is one of the strongest rising trends of our century and it is definetely not a bubble. There is no single industry where the services spending is not continously growing. Especially in IT, the purchasing and delivery of services is quite complex, diverse and difficult to manage. Human factor is the driving force but yet it introduces intangibility, uncertainity and variability to the business. To thrive in the hugely comptetive market, services organisations have to invest a significant amount in the processes and their people, be flexible and strong enough to survive the changing environements of the service domain and fluctiating demand. They build excellent relationships to customers and know their needs and develop the capacity to forecast the demand. In times of fluctiating demand there has to be a plan B to overcome the challanges financially and morally in the organisation. This might include many organisational skills like hiring talent fast, getting the workforce provide overtime without loss of quality, building financial buffers to bridge low demand periods while keeping the capacity. And finally, a services organisation must have the ability to acquire new skills and offer new services continously, the comfort zone of services for cash cows should not be the only domain they show their presence. There is no sustainable growth possible  in IT services without  intelligent risk taking.

(Special thanks to my former MBA classmates Sara Al Murad, Annette Barth, Gianmarco Dionisio and Peter Ippy who worked with me on service chains & purchasing and inspired me with our findings and discussions)

The Job That Made Me A Manager

Today it is out : my colleagues received the mail announcing my transition to another team as a manager at Microsoft. Now it really feels real, now I realise that I am leaving this office and the organization that gave me the chance to take on the challange to build a team. I came as a motivated IT professional and project manager and I am leaving as a manager. Feels similar like what I felt when leaving my parents’ house 16 years ago.

So looking back all the things I have done here , here are some of my “read it, do it” notes I made:

Lessons learned  top list

  1.  When it comes to figuring out the reasons and facts about unexpected output or behavior, never assume things or use interpretation based on 3rd party information. Go talk to people,  your decisions and plans have to be based on the data and facts you directly obtain from people you trust.
  2.  Make it crystal clear what you expect from individuals and what the “real deal” goals are for your team. Do not attempt to tell them how to do their jobs and use their expertise.
  3.  You want to make the call and make a decision yourself enforcing your opinion? Fine. But do inform people about it and tell them why. ( It is not a naturally acceptable thing that you get to decide about things on your own all the time.)
  4.  Figure out the Must-Dos and Dont-Dos in your team , set the rules to function, grow and work effectively with you in your team for your employees.
  5.  You don’t have to have all the answers of the questions. But you have to listen to all of them and give the best information you can to your team.
  6.  Face to face conversations with your team members are vital for your job. See them as important as the meetings with your boss or CEO. Do not turn them back when they request a one on one talk. (you are a peoples manager and tell your people you are too busy to talk to them?! …. hmmm…. no does not really make sense)
  7.  You have to take time for each employee, at least an 1-2 hours a month. Go talk to them or work on their career, development, think about their participation in the team and their development potential.
  8.  Work hard on the trust in your relationships with your subordinates. If they give you honest and open feedback, REAL feedback , you can drastically improve yourself (or at least know when and why you sometimes suck)
  9.  If you are feeling angry with somebody or something…There is something wrong with YOU. Go calm down and think about it once again.
  10.  Accept the fact that some people and some sh*tty things cannot be changed so easily. Some things are out of your reach. Stop spending your energy on them  and avoid damaging your mental health for nonsense. Protect yourself and your team from those things.
  11.  Managers delegate! They have their great team to work on the daily challenges, they have to look into the future and work on the long-term plans instead. Be visionary and lead your team towards your visions. (yes let your team fix the last bug you recognized…I know you would have fun doing it too…)
  12.  The best manager is who makes herself redundant with time, one that implements the self managing and growing team or individuals. When that state is reached she should move on. I firmly believe in this especially when it comes to people management. You cannot optimally and productively lead the same team for long…How long? I don’t know, it depends on the field I guess. ( >5 years  sounds a verry good time to start considering a move)
  13.  Do not put your team in a cocoon. It is not only about  you and them. It is the whole team interacting with the whole enterprise.
  14.  You really do not have to go to all the meetings, even if the invitation is coming from upper levels. Do not hesitate to say no if you think it is the better option for your work.
  15.  Meetings are great, ONLY if the people you invited are interested in what you want to tell them or in the result of the meeting. A meeting without meeting notes and/or followup points has not taken place.
  16.  Documentation is great and has to be given priority and incentives to be done. But there is no way that you can turn all the valuable and useful tacit information to an easily accessible , written form. Shadow the people carrying that knowhow you cannot get (for whatever reason) externalized.
  17.  Yes, you cannot change people’s character. But…Team culture is a product of processes and the way of getting things done at work. As a manager you have amazing power to drive the culture.
  18.  Be honest. Base your critique on facts.
  19.  Do not reinvent the wheel, be alert about the individuals with that tendency. You need to help them have fun doing something else.
  20.  Managers must be managed too. Manage yours : have a communication and collaboration strategy. Know his/her style and adapt to it.
  21.  Run away and save your day if people start talking about ops vs. dev or vice versa. Everything else is a better use of your time.
  22.  Try to set a good example for work-life balance for your people. Do not work more than 10 hours or do overtime if it is not really necessary. But do kick a*s when the situation calls for it!
  23.  Fingerpointing in the team? : Act against it asap, make all understand that it is not tolarated and it can have consequences. It is the worst thing ever, total productivity and team killer.
  24.  Kill the procrastination monster in yourself and in your team!
  25.  Celebrate success but know to accept the failures and flops. The BEST learning is from mistakes and failures if you have the culture for it.

Quality

Quality management is one of the hottest topics in management and in discussions about achieving competitive advantage. Especially service quality…Because the so called “western” world is more or less hopeless to compete against cost and labour advantages in production of China , India and the like. Services and high quality service chains will define te future of western economies. So I am going to talk about service quality today. What kind of services? Huh, basically you can name it : laundary service, IT consulting services, the entertainment services in a life concert…. At the end of the day the core of services will be the same. On the other side being an IT manager, I reckon I will be heavily biased Smile
Starting with the culture
Oftentimes when you get to hear someone talking about quality, all you hear is buzz wors like Six Sigma, TQM, continuous integration, bla bla bla. The quality, especially in services sector is all about leadership and culture in the company. It is the people , not the process described in 600 pages or some framework that leverage the quality and increase the added value.  So the very first step in creating outstanding quality is creating the quality culture and the visionary leadership advocating for it.
I think there is no unique recipe for that but still it comes to basic management practices every manager gets to hear in every management training, book or discussion:
  • Set goals and vision for your organisation and show management’s commitment to them (include and focus quality when doing this)
  • Reward developing and learning members of the team.  I have recently read this great sentence in a book “People follow learners. They will not follow knowers.”
  • Quality is a team work, there is no place for command and control in that game. Delegate , delegate and empower your people!
  • Status quo = decreasing quality. I recommend reading this sentence at least 5 times a day.

Defining quality and updating the definition regularly

It is really important that quality is a concept that team members providing services can define and identify themselves with. Like business and services , the definition and meaning of quality for an organisation should evolve and change with time. The quality  of today is not quality of next year ,maybe not even next month.

Defining and measuring product quality is much easier : there is  huge collected experience in the world about product quality. Services on the other side are more complex by nature and the supply chains for services are still not mature in most fields. Therefore controlling and assessing tangible and intangible parameters are still ambiguous and far from being standardized.  One of the attempts in this direction is the SERVEQUAL dimensions , developed by Zeithaml, Parasuraman, and Berry. SERVEQUAL stands for reliability, responsiveness, competence, access, courtesy, communication, credibility, security, understanding the customer, and tangibles.  Another researcher Chakrapani  talks about the 3 basic methods of service quality : basic quality , continued availibility of quality, exceeding expectations. Taguchi, the Japanese engineer and cofounder of modern quality theory, says that consistency, uniformity and minimal variance are critical to quality.

I will not discuss about each dimension mentioned but I do believe agreeing on some dimensions, paramaters (whatever you call it) is the right approach to set the scope and the associated goals related to services. It helps the management and the work force to get clear and more focused on the shared objectives for themselves and for the services they provide, triggers the natural tendency of the team to be  creative and innovative to reach desired results.

Defining and understanding the quality for the organization must be a process, the dimensions and the target levels should be remembered, reviewed, updated and repeated regularly. (very regularly. once a year in company meeting is not the quality I am talking about Wink)

Implementing A Quality Management System

One of the standard and wiki-like definitions of a QMS is  : a management system to direct and control an organization with regard to quality. Depending on the size , purpose and resources of the organization the quality system to be implemented can vary. It might be a Word document defining the basic processes and the critical known metrics. Or it can be a whole big detailed paradigm like Six Sigma or something like ISO standards complience that might affect the organization ,  hierarchy and work practices of people.

On the bottomline, such a system has to be effective , it has to cover all your vital activities and processes that drive your competitive advantage and core business. Effective meaning, it should not create more paperwork (at least not without a VERY good reason) and yet another process to ignore or hate for the employees. It must help people do right things in a right way the first time and every time.

Using simple , efficient (almost no brainer) methods and tools can help :

  • Checklists
  • Benchmarking (with some other org that is better than you)
  • Flow charts, visual presentations of processes
  • Stakeholder surveys and monitoring of trends
  • Root cause analysis to find the causes of problems and fixing them
  • Experimenting/prototyping

Of course big fishes (Fortune 500 and the like) play in a much different league. They depend on quality management to sustaing growth and ensure survival. So the do invest a lot of resources on quality and follow more formal processes.

And…Remember KISS principle : keep it simple sexy!

Light bulb PS : From Six Sigma,TQM, Kaizen to ITIL , everything I see and read brings me back to Edward Deming and his PDCA (Plan , do, check , act) cycle.  I highly recommend performing an online search about Deming and his work to everybody who are interested in this topic.

Share

%d bloggers like this: