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

Magnetic Leaders

Some great leaders, most of them extremely successful have one thing in common : the way they talk, move and address people is so authentic and so fun. They have a natural attraction, some kind of a magnetic field. You don’t get bored listening to them an hour-long on the stage presenting their business, you look for opportunities to meet and spend time with them. They lead the people not through what they say but mainly this weird magnetic field pulling you with them.

I have been observing these species and asking myself what one needs to have this leaders’ aura. I have read books and attended various trainings/courses about micromessaging, presentation skills, body language and the like. They were all very helpful to improve certain leadership skills but the question about how build a magnetic field stayed unanswered.

Do I have the answer now? Not exactly..But I am a bit closer to it. Somebody I met, somebody who can create amazing influence and impact on everybody she meets within minutes has helped me to understand what the “magnet” really is.

This weird,strage magnet that keeps people around these leaders hast to do the feeling of sincerity and openness that radiates from a leader. It is a feeling…Oftentimes it is not the reality. And it does not matter! These magnetic people put themselves in a mode that their voice , body and mood signalizes that they are 100% interested in the audience and what is happening to them.They don’t aim to position themselves as a manager or prove their superiority.They get accepted and honoured by talking, moving, looking and listening with 100% dedication to the audience. They look open and receptive to everything in those moments : sympathy, attacks,dislike or hate. They give the others time and space, they offer them topics and energy to be shared, their messages are never about enforcing goals. People feel that this special magnetism has something to do with the leader himself, all what is done and said is about a common cause that is offered and shared within a space and time owned by the leader and the others. As a result, they stay connected to him and show amazing acceptance to the messages being sent. Messages, that exactly serves the leader’s goals. Exactly the way he wants…. Fascinating.

And from Gandhi to dictators, CEOs to smart teachers, some people use this magnet with good will or as a manipulative weapon to connect with audiences and lead them. You can be born with  the talent or it can be learned, obviously. I was so surprised to find out that almost every high level executive and politician today has a couch or a professional to train these skills. There are various couching models based on different copcepts : NLP, voice and body language training, outfits that are tailored to the leader and his audience and improving empathy skills are just a few of them. The investment seems to pay off quite well, even if they are not sympathetic, most of the trained leaders manage to be quite impressive personalities.

Is it manipulation or a social skill? Maybe they are all the same thing anyways.

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)

Toxic Organizations

Everytime I talk to friends who are changing jobs, 3 out of 5 tell me they are running away from their toxic org. Now being about to change my job myself, I kept thinking about it. No, I wasn’t in a toxic org but I do know how it looks like.

Toxic organizations are poisonous, it is like swiming with the sharks while trying to appear as big as possible not to be eaten,you need strong nerves and competitive powers to exist at all…. If you have 5+ years of experience and hopped a couple of jobs in your past, it is likely that you know what I am talking about.  Working at places like this is like living in a battle field 8 hours a day or more every day.

The toxic battle…Either the whole staff is involved or a couple of colleagues give you  really hard time with their apetite for more and more power or their need to “know everything” , “be the best”. Some uses tradition or enforced rules to suppress everything not originating from them or somehow new. If you are an individual contributor, who has fun at his/her job and ready to try out ideas and do some cool or different things , you will appear in their radar. You get sick of the fact that even your own manager has to find something wrong with every suggestion you make, you lost your proactive impulses because noone ever lets you do something with your expertise without getting approval from the lead, implementing his/her adjustments and ideas in addition  and organizing 5 meetings about it.

 If you are a manager, everything you do and say, every success of your team increase the tension and you find yourself very soon in a power game. Headcounts, decision making power and territories to control in the enterprise are the main drivers. It is all about extending the teams size and influence. No body cares about the changing needs of the busisness or if their team has reached the limit they can optimally handle. Decision making..It is all about bringing the “own” team in to a key role and being able to control the processes. Assertive alpha animals dominate the whole domain. Probably you are or are becoming the managers I was mentioning above. You are probably poisened by your own team as well. Constantly you have the feeling at least a part of your team does not really accept your leadership and underestimates you, you somehow know that they have been gossiping and joking about you when you are not around and they could easily trade you for another manager with the next opportunity. Maybe you have lost your trust and started micromanging and overcontrolling them. Probably it made things worse and they dont take responsibility if they dont have to , they are not productive if not being monitored closely. You gotta come up with the decisions that matter and hold the accountability. They argue with you and with each other, telling how badly things are being handled and critisizing every single thing.  Any constructive suggestion to change something or do something better is punished with hours of critique and discussion, almost humiliating. You are using your authority now to hold the team together and not fall apart. They changed you and your style. They made you that guy they constantly joke about….

In a toxic org, collaboration is a song you hear again and again from your VP s and your own boss sing. Nobody believes in it. Company goals and objectives might be partly and fully rejected in reality , when they don’t comply to the rules of the game in the toxic organization. The employees have to choose their side , build networks and defence mechanisms. Fingerpointing, lack of transparency, emotional burst outs are typical signs you can observe every day. You come to work with a feeling there are people not finding you ok no matter what you do , you go to meetings with some idea you believe in and you somehow know that  nobody would support it even if it were the best idea the’d heard. Nobody tells what they really think but everybody senses it. You learn to be alert and not to trust anybody quite soon in the texic org.

And one day you are out.! You leave the battel field. First you cannot believe it is happening, then a wierd feeling of happiness fills you in days long. Yayyy! Your new position and org is really different and most of  them seem so friendly. You are asked constantly if you need help, they tell you their honest opinion during discussions, when you talk to your boss you dont get the feeling he is behaving weird and uneasy after 5 minutes , as if he had something way more important and urgent to do. If you are a manager, you are surprised how much credit you got from your subordinates and how willing they are to get on the same page with you and let you lead.

Yes, I can imagine. You have this wierd funny feeling inside. Is it all real? Is this happening? You should be extra careful before you open up, ha?  What are you going to do? Obviosly you know how to play in the battle field, even if you werent a killer yourself.  It is not gonna be so easy to be healed and you gotto consciously work on your feelings, subconscious and learn how to trust others again. In this new world you were longing for , you are still  an alien.

(And what to do about toxic orgs? You need management that understands the urgency of  the situation and initiates a culture change. Maybe it is a nice topic for the next posting.🙂 )

Lean IT Operations : Opsban

Agile methods has been accepted for a while now, many companies and organizations are on their way to implement “lean” agile systems and creating their continously improving Scrum system, which is also called Scrumban. It is basically a evolution of Scrum using the concepts of the Japanese lean Kanban methods. There are enourmous amount of resources and discussions about Scrumban and I won’t be adding much to that. (yet🙂 )  I am writing today actually about lean operations with Kanban , i.e. Opsban!!!

It makes so much more sense to start applying lean and “fixed work being worked on” principles in IT operations. You might have a classical ops team or a new modern devops structure or your devs are somehow managing ops in your organisation. It does not matter at all, ops is the area where bad prioritisation of workflows kills productivity and speed of services delivery, ops is the place where you need an effective PULL mechanism the most. Just in time management ? : No ops would be/should be setting up an infrastructure module or delivering a service until it becomes necessary and requested. Inventory issues need to be handled and it is not less critical than the inventory management of Toyota for a company depending on its online or offline IT services.

At the end of the day, Work In Progress has to be controlled and should not exceed the limits. This work includes the incidents, meaning your service downtimes, crashing services , SLA violations etc. Speaking of Scrum, I really doubt that IT ops team can commit to 1-4 week sprints. Many issues need to be resolved immediately , some work takes months and cannot be splitted well into subtasks,  you have no choice but change your priorities and start working on something else if the situation calls for it, you gotta keep the show going. Yes, I know, ops is and must be more than keeping the lights on and I agree with that too. And do keep your devops folks and engage them in scrum(ban) of your development teams. I just think it won’t be enough to reach the optimum of software and IT services value chain.

Kanban is a signalling system . It includes a physical or a digital Kanban board where the whole team can visuall see what work is in the system and should be handled (WIP) and get a perfect overview of the production environement. The demand and conditions pull the deliverables out of IT operations. And you have capacity limit of the work in progress, which keeps your pipeline clean, managable and fast! This is the cure of ticket blindness in many organisations : tickets are created one after the other, ops engineers get more tickets than they can process and lose the whole picture of their business. Such a system is called a push environement. The work is “pushed” into the members , who get overloded usually with the same type of work.  These people get bored and cause trouble when they are sick or on holiday.Some stuff gets forgotten, pending or suspended for ages. And seriously, how do you create a team feeling in that environement????

Recently I came accross with a blog which describes how Kanban can work for services and Scrum developement. And this is the visual presentation of what I was trying to put into words for days :

Kanban for services

So I’d recommend you to go and read Jaibeer’s blog if you are interested.

The main question for me about this appreach is who should be making the assignements to the backlog and decide what work gets done with what priority. It must be partly automated or managed by certain processes (like capacity management, monitoring ….). The interruptions with incidents and SLA requirements are still not adressed well enough. And you know, you should not limit what an IT professional is doing with a board with a set of cards, there must be at least some freedom and autohority given to them to decide what they are working on and assess the priority of the situation themselves. If your servers are crashing, do not expect ops people to create red cards and paste into the “urgent” section of your Kanban board. After the situation is sorted out you can go ahead and reflect on it and yeah maybe create a card. There must be trust within the team where everybody is sure that the members are doing their best to meet the requirements of the operational environement. And the Kanban “guidelines” are to be followed when firefighting or exceptions are not on your way.

Second question is innovation. How do I get my people’s  crazy ideas tested out on my Kanban board? Where is the time and incentive to forget about “effectiveness” and look for new ways and have fun? Why not risk wasting a bit of time or resources, if the members would learn from it? I can imagine giving people a 10-20% buffer to strech themselves and go out if the box, where they dont need to care about the Kanban board or whatever place the “real” work is shown. A team utilized constantly more than 80-85% for “usual”ops work is not my ideal and no lean methodology is going to change that.

Follow

Get every new post delivered to your Inbox.

Join 521 other followers

%d bloggers like this: