My grand daughter, who is 5 year old, operates my Samsung note better than me. Contemplating on why is it so – I spend almost couple of hours on note everyday myself – I realized that what makes her better is her childlike curiosity.

This curiosity to learn something new, day after day, every day.   When was the last time you learnt something new?  When was the last time you took a conscious step towards self-development? Curiosity to learn something must be backed by an innate desire to improve oneself, to become the best version of ourselves. It is the only way to remain relevant in the hyper-competitive markets today.

The same concept should be applied in the Agile projects, we are always running after getting the user stories done and churned out for the product owner. Yes, this is required, but one should step back and take a different view, are we learning anything new, have we added value to our existing knowledge base, are we much better skilled as compared to the start of the sprint, can we proclaim that we now know a trick or two.

When speak of adding value to our customers, shouldn’t we not add value to ourselves, as we are the first customers to ourselves

We always talk and speak about the improvement in velocity and team work, that cannot happen automatically, the organization needs to invest in this area, by providing and allowing a time-box element to each and every member of the team, I recommend a time-box of 5-10% of the sprint time allocated to each team member of the development team (on a different thought, it should include the scrum master and the product owner also). If the sprint cycle is 2 weeks (10 days = 80 hrs.), then the minimum time-box would be 4 hrs. / sprint to a maximum of 8 hrs. / sprint.

Organization should be aware that providing this time to learning and development will reduce the velocity in near term, but there would be major impact in terms of quality, knowledge gain, productivity improvements, team collaboration.

This time allocation should be used by the team members to improve their skills in any area of their interest, which would ultimately help the product to develop and grow better and thereby improve the required velocity. It should be the task allocated to the Scrum Master to ensure that all the team members are using this time-boxed element in the most productive way. One also needs to understand that a Scrum master would also be required to improve and master the skills that are important to the role that he / she is playing to.

Each sprint , the team should have a dedicated time and name it as – ‘Learning with Agility’.
• Define a dedicated time slot. It would be a good idea to have a time slot of 4 hrs planned in the early part of the sprint cycle in week 2
• This week, every sprint, learn a new thing – pick up a functional skill from a colleague, or improve the product knowledge, master an automation tool, learn new elements of coding (do a little unsaid spike)
• learn about a behavioural skill

Learning is not about mastering the hard skills, it includes all those elements that make you a better team member, a team player and more so a better person

Your learning is in your hands and you are the product owner of the product that is you. Take advantage of the fact that you spend 8 hours every day most of the week in an organization that promises you learning opportunities. You have, at your fingertips, access to a whole host of behavioural learning through social media , hundreds of thousands of articles in web, , ride the huge wave of Massive Online Open Courses with the many courses that are available online freely – make use of all these resources to better yourself today.

The above mentioned are but a few of the avenues for learning. Such platforms are present everywhere – the internet, libraries, even in day-to-day interactions with colleagues, it’s you who has to take the first step.

At the risk of re-iterating, I’d say again – that the onus of your learning lies with you. No one can help develop you but you yourself. This week and for the ones to come, promise yourself a week full of rich learning.

The day you stop learning, is the day you stop practising Agile ….. So Learn each day and be agile every moment

Agile Scrum – Nothing more than a COMMON Sense approach

Last few years has really seen the growth of Agile – Scrum adoption in the IT Industry. Organizations are adopting dime by dozen concept in moving towards Agile. Every Software person (whether a developer or tester) is bent on adopting and having the agile experience on their resume / profile. Well nothing wrong with this, But if all (or should I say most) of the organizations are adopting agile and its related frameworks and all the workshops are going full, why the quality of the SW delivered has not improved in the same proportion, Are we not having things which are behind schedule?, are we not working late to complete the commitments that we have given?.

Same happened with Lean applied to manufacturing; people learned the Toyota-ish words but didn’t embrace the philosophy. We all have got certified in various elements, but have not improved. Well, i ain’t talking about the improvements exponentially, but at least by some percentage. So do we say that the agile model is fundamentally faulty or it is our adoption which is creating the unnecessary trouble.

If one thinks that Agile is defined by buzzwords, it is no wonder you not sure can will come or can’t, to me it should come can make it work. Agile is a mindset that leads to:
• Centralized change management to projects
• cutting projects into manageable chunks,
• Insisting on end user ownership, etc.

One of the areas that the industry has defaulted itself is in the area of focusing on Project Management and forgetting about Software Engineering piece of the system. We have conveniently forgotten the idea that every coin has two sides and unfortunately we have focused only on one side of the coin in agile

Just because you’ve travelled in a CAR doesn’t mean you can drive it (like for me, “I can travel in CAR, but cannot drive the same”). Same thing with an agile process, too many people use the buzz words and get the quickie certifications that the industry requires in order to get the job. They did the same thing to RUP, OOAD and OOAP when it came out; everyone was doing it theoretically, yet they really didn’t apply practically and that’s where they failed. If you’re going to say you are using an agile process then really learn it, really do it, and really be it or stop saying you are agile and find something else to blame piss poor requirements, design, and software on.

Personally, for me, Agile Scrum comprises of good common sense elements, doing small things, and doing regular and periodic delivery to the customers / clients or management / end user (whatever the case may be). My concept of Agile is to deliver less, but deliver of good quality, Even if one delivers a great amount of software, but if it does not work at the customer site, how does it really matter. But as they say these days “COMMON SENSE is NOT SO COMMON”.

My belief is that there is a wide range of people using the term “agile” but of these also there are two types of people
1. Some people have a lot of experience doing software development and can use it to create much better software.
2.And other are those people who use the term vaguely in order to sound intelligent and flexible.

There is a fundamental understanding flaw of what agile development is about. There are many people who see agile as anti-process and an excuse to work in an informal and ad hoc manner, While the actual objective of agile development is to follow an agile process and not eliminate process completely. There are unfortunately companies who operate in a chaotic manner and try giving this approach legitimacy by calling it “We Work the Agile Way”. On the other hand, there are companies which, using an agile methodology in the way it was intended, have seen great success.

Agile is abused as a methodology, particularly in India, where there is a culture of pathetic unplanned and managed software development is prevalent. Most of agile principles are not followed and adhered to… It is more of a jargon that is used in the industry to boost up a few resumes and profiles. It is quite surprising when we get assignments to have resources certified for CSM (Certified Scrum Master) or PMI ACP (Agile Certified practitioner), because the client / customers who are giving business to my local clients (In India) want certified resources on the project, I am not sure if the customer understands that getting a certificate and implementing the practices in true spirits are two different ball games… but alas who cares and why should we. On one hand we are getting business (so I am billable) and secondly the resource is getting a new additional element on his / her resume, who would complaint and not sure if the original customer, over a period of years has performed a ROI or cost benefit analysis of having all the resources working for their project certified of any value ….

The bigger question for me is yet to be answered … our management, customers and clients want agile to be practiced, how many of them even understand agile, have they ever got oriented on agile, do they understand the basic principle and thought process behind agile … I afraid not ….

In my long experience in IT industry and more specifically in SW development, certain things are consistent, and they aren’t Waterfall. Project Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of documenting their unit test plans and so on …

One should not forget that we live in the real world, we are also the development team who would have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own element or buzzword.

Could I rename it to Sensible /Common Sense way of SW Development, anyone?

Matured teams – Do not create great Scrum Masters

Disclaimer – Not many may / would agree with the thoughts as expressed in this post.

===================================================================

A successful Scrum Master must lead by example, must have an open mind to listen to others. A good scrum master is the one who is able to visualize the future for the project and lead the team in that direction. A good scrum master has a deep sense of commitment to the project, its stakeholders and more importantly to its team, He should be a person with a lot of passion about the future. Guiding the team from the front in times of crisis. Scrum Master should be constantly encouraging his / her team to get the very best through his infectious energy and unwavering optimism

When you have a matured team, which has worked together for many products and sprints / releases, they start to develop understanding of each other’s behaviours, skills, strengths and areas of improvement. They have worked together for a longer time, they have good coordination across and among the team, They excel technically well and are producing the outputs as needed and required with quality built, In such a kind of scenario, Scrum Master would be relegated to back seat, as the process of Scrum would be typically on a cruise control mode. Having said this, I do not mean, that there would no issues / impediments to resolve, but they would far and few due to internal coordination of the team.

A matured team is excepted to have a climate of trust and openness, that is, a positive atmosphere. A positive atmosphere indicates that members of the team are committed and involved. It means that people are comfortable enough with one another to be creative, take risks, and make mistakes. It also means that you may hear plenty of laughter, and research shows that people who are enjoying themselves are more productive than those who dislike what they are doing. In such a scenario, the role of the scrum master is to provide minimal inputs, as the things are working
Trust is by far the most important ingredient of a positive atmosphere. Matured team members reach a point where they can trust one another. Trust and credibility can be described behaviorally. They can be seen in a more logical way than you might think. Consider this …. What do people need to do to build trust with you?

What came to mind first? Was it honesty? Dependability? Sincerity? Open-mindedness? For a tenured team, all these elements would already be factored in …

A mature team, by definition, also offers little room for bigger improvements and growth. Even if you succeed in making room for yourself in the team, it is difficult to find new processes and introduce significant innovations that push the team forward. This challenge also introduces a key benefit of entering a mature team with a strong, innovative thought process. However, finding new ways to distribute ideas or attract interest from the team is tough.

It is important for us to understand that going from ZERO to SIXTY is much simpler, easier and faster as compared to moving from NINETY to NINETY TWO percent, as the areas for improvement reduce and the smallest of improvement takes a longer period of time to implement.

The costs to enter a mature team successfully are usually high. It takes much more time, effort and energy to enter as a new minted Scrum master, because you have to establish a reputation and promote yourself to get team to understand you and move away towards a new thought process. You also have to invest in research and development to give team something distinct in your ideas and thinking.

The opportunity for the scrum master to demonstrate his or her skills in this kind of an environment, gets limited and this would reduce the elements of learning and improvement for the scrum master. It is important for us to realize and appreciate that rough seas, make skilful and great sailors, smooth seas would not, the same analogy can be applied to the Scrum Master scenario also. Grooming of an individual is also a function of exposing the person to variety of elements, situations, challenges and more importantly sufficiently empowering them.

When we have a new team freshly minted, there is a huge amount of opportunity for the scrum master to demonstrate and utilize the skills, as issues, knowledge, processes, approach would all be required to be explained to all , there would be high amount of coaching, mentoring opportunity available for the scrum master. Scrum Master in such scenario’s would be required to use his skills to the full potential, as the team is new to agile, new to this concept, may be working together for the first time, exposure of small deliverables and increments.

Many a times it has been observed, that post the training of certified scrum master, the person / resource is now supposed to act as a Full time, well prepared Scrum Master, it is as good as learning to drive by reading a manual. This thought process needs to change in the industry.

New Scrum masters may be paired with veterans. Innovations and new thought process should be encouraged. Different personalities, voices, values, and approaches spark interest, keep attention, and prevent boredom to the team also

A good scrum master should and always emphasize that all five fingers are equally important and each of them has a role to play in perfect synchronized coordination of any act by a person. The same hold true for the a good agile team

As we say in Agile, that the team should be allowed a set of time to improve, excel and learn new elements each sprint / iteration, the same logic needs to be applied for the scrum master also, We need to ensure that the scrum master also upgrades his skill sets at end each sprint.

Certifications Boon or Bane? – You Decide

“Third party certification through reputable organizations can be an important tool for small businesses and the gives company the assurance that your suppliers are comprised of the ownership they claim.”

Certification is now a full-fledged industry, everyone is running around it like there is no tomorrow, The craze of the certifications is more seen in the IT sector as compared to the other sectors, specifically for Project Management, Agile, Six Sigma and not to forget at the organizational level for things like CMMI and ISO’s of the world

Senior management should now take 2 step backwards and perform a review of all the money that was spent on certifications, did we really get the ROI or the Cost Benefit analysis? Can we provide the measures that certifications have really helped the productivity of the individual or the group or the organization improve. Would the organization be able to show visible improvements in their TOP or BOTTOM line?

I have my own doubts of the data availability, a good part is that most of these certifications like PMP, Agile , CMMI and so on …. Advocate the usage of metrics and measurement to understand how things are moving in the system, but we rarely use these measurements to prove that the money that we have spent has been really put to good use.

Industry and organizations are going crazy over certifications and spend a huge amount of dollars in acquiring a certificate, to be there on the Wall. I recollect an interesting conversation with a Quality Head for one of the esteemed organization, who had just delivered a CMMI Level 5 successful appraisal for the organization, He was mentioning that his job is over here and with the experience of this journey he plans to move on to a different organization at a better position and obviously a better packet to carry home, On response to my curiosity based questions, he responded that the he has nothing more to add to the current organization. This made me think, that did the organization hire him to get a certificate on the wall types, Is getting certificate the only requirement of the organization, where there improvements in the system, did the ROI of the organization improve? Did the defect count go down, or did they have better schedule performance.

We, in the industry have failed to understand the value and reasons for certification, It has become more of a decoration element on the wall and to gain a few bragging brownies

Project management certifications are booming. However, it seems to me that the main beneficiaries of the certification gold rush are the certifiers, not the certified. There are a lot of articles aimed convincing people of the value of certifications. Here I take a different, and possibly contrary approach: I’ll give you two common, but (in my opinion) wrong, reasons for pursuing PM certification.

My motivation for writing this post is a recent conversation I had with a participant of my PMP batch. It went like this:

“Do you think a PM certification is worth the effort?”

“Depends on what you want out of it,” I replied.

“Well I reckon it will make me a better project manager and help me stand out from the crowd .”

Now I don’t remember what I said in reply, but he’s wrong on both counts. Here’s why:

1. To become a competent project manager: A cert does not a PM make. Preparing for a certification will teach you formal project management processes as decreed by a particular certifying authority. These processes are easy to learn by reading a book or two. The “hard bits” of project management – negotiation, people skills, crisis management, conflict resolution, prioritization, stakeholder management (I could go on and on but I’m sure you get my point) – are not, and cannot be, learnt through certification.

2. To stand out from the crowd: The fallacy here is easy to see: certifying authorities push their credentials like there’s no tomorrow, hence the number of people gaining certs is growing rapidly. That being so, the “stand out from the crowd” factor is getting smaller and smaller every day.

Before I conclude, I should come clean and admit that I have a cert or two. My main reason for getting certified was (is!) that it is a good way to learn about commonly used project management processes and the associated terminology. The certs don’t make me a better project manager, and they won’t help me get that dream job either. However, they do help me recognize jargon-laden bull dust when I hear it (which, unfortunately, is quite often).

In the end, formal knowledge is always useful. So, gaining a cert won’t hurt, but be sure you aren’t doing it for the wrong reasons.

Agile, But not Agile

I am sure that is post of mine would resonate with the readers with respect to that we are Agile, but Not Agile. The best part of the story is that most of the organization in India are doing something or the other in the world of Agile and trying to make their hands dirty with the concept and implementation of Agile.

Not sure if the organizations that have adopted Agile, have done any retrospective on their adoption of Agile, we expect that at the end of the iteration / sprint cycle, the team would perform the retrospective and learn from their practices that needs to be improved. Not sure why the same yard stick is not applied at the organizational level. The management expects all the principles and practices to be applied at the team level, but when it comes to its own application, they have washed their hands off

I am finding it very difficult in India for Agile to be practiced in true spirits, not saying that all organizations can be clubbed together, nor am I trying to paint the town red, but the real story is that in most of the places, I have not observed majority of the Agile Manifesto and Principles adopted and done in the true manner

Most of the people and the Agilist that I have met have given the impression of working with Agile and related stuff with the waterfall mindset. Not sure if the required change would come via this element / approach.

Speaking on the same, Lets discuss one of the principles of Agile …. “Customer and the Development Team should speak daily”, All of the agile methods require that the Customer (in this case the Product Owner) would be based at the same location as that of the team, but this is hardly practiced in real life execution of projects, due to the Onsite / Offshore engagement models, where the product owner is not located in the same location as that of the development team. Have observed practices such as proxy product owner, it is like complicating the matters beyond repairs, If the Proxy PO can do the job, then why have the PO? During my training and consulting with various customers, Have always heard that if we have any query to resolve with respect to the user stories, it is difficult, as we have nobody to bank upon, the queries are delayed, at times information is provided at the eleventh hour. This has its own impact on the quality of the deliverable that we make to the customer.

One of the other major issues faced by team adopting Agile and related elements in India is the changes that come in the sprint after the commitment has been done during sprint planning meeting. It is stated and given that no changes in duration or goals of the sprint, but this is not in place for majority of the organization. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. This encourages poor and irresponsible planning while hiding its effects. As iterations / sprint continue and the defect list grows, the customer becomes more frustrated—not only because of the lack of quality, but because delivery expectations aren’t being met either. The only way the project can handle this is by adding iterations / sprints. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It’s the How to Develop Next-Generation Scrum Masters / Agile Project Managers role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

Off-late I am in touch with a number of customer, who want to actually redefine the concept of Agile to suit their requirements and needs of working, well I see nothing wrong in this approach, but my recommendation is not qualify that we are following Agile, it is a misnomer, We are giving false impression and views to the world of our capabilities and understanding of Agile

People love certifications in the industry where I work. But when a particular methodology gets popular enough that a certification industry rises around it, organizations try to adopt that methodology without bothering to understand it. It’s as if certification replaces the need for thinking or experimenting. It becomes a check in a box: “We’re certified, therefore we know what we’re doing and you should hire us.” The primary focus becomes figuring out what you need to go to get certified; figuring out ways to actually improve productivity becomes secondary. That’s the problem I have with certification – I’ve seen it happen multiple times (and even been involved in it), but it’s particularly ironic with Agile development.

There’s a reason behind the demand for certification – it’s human nature to want a simple way of discriminating those who know what they’re doing from those who don’t (especially if you don’t either) – so I’m not sure there’s a good solution. In any case, I don’t have a problem with scrum training, just certification.

It high time, that we re-channelize our focus and energy to do the real thing rather than running after pseudo stuff ….. My prediction, Agile has lived its utility (though more than 70% of the IT industry does not implement and practice the way it should be done), We are now waiting for the next BIG wave to come in and that in my view would be DEVOPS

Creating, Sustaining and Scaling – Agile Development Team

The squad (aka Development team in Agile) – nine folks. The number of guys that could fit in a tent,” It has been identified that the way to build a scalable organization is to focus on the basic building blocks – small, stable, multidisciplinary teams that are expected to independently tackle problems, make decisions, and get things done.

“When it comes to building a deeply efficient engineering organization, there are several things you can do to move the needle:
• Build strong teams first. Assign them problems later.
• Keep teams together.
• Go modular. Remove dependencies.
• Establish a short, regular ship cycle.”

Concept is to have a decent team size that is the two-pizza team – a team small enough to be fed with two pizzas. A team includes everyone needed to design, deliver, and support the service – from specifications to operations. If a service is too large for a two-pizza team, Organization should split the service into smaller pieces rather than to combine teams to deal with the larger service, because this preserves the dynamic interactions of small teams.

WHAT COULD GO WRONG?

If it works for larger organizations like Salesforce, Amazon and Twitter, surely it will work for you… So you form a lot of small, independent, multidisciplinary teams and you are careful to give them all clear goals. What could go wrong with that?

THE DILEMMA

It is a beautiful thing when the building block squads of an organization gel into high performance teams and can be counted on to meet challenging goals. But tricky part is, once you create these strong independent teams, how do you get them to work together? How do teams maintain their autonomous character while working in concert with an increasingly large network of other teams? How do you make sure that each team has a clear goal, but none of the goals are in conflict?

In an agile environment, the Scrum Master’s role is to set up strong teams, to be sure, but it is also to devise a system – let’s call it a goal system –which assigns goals to teams. This is no easy task. Teams need clear, meaningful goals; they have to be the right goals; teams must have the capacity, capability and autonomy to achieve their goals; and most important, the goals cannot conflict with each other.

One of the things Scrum has contributed to the practice of software development is the idea that small autonomous teams perform much better than large project teams or single-discipline teams that work in sequence. So Scrum provides the building blocks of scale, but unfortunately, it does not contain a scalable system for choosing team goals, making sure they contribute to organizational goals and are in sync with the goals of other teams. So we need to look elsewhere for ways to set up a goal system.

THE THEORY OF CONSTRAINTS

When the Constraint is Technical

The first step – after clarifying the overall system purpose and goal – is to find the biggest constraint to achieving that goal. For purpose of discussion, let’s choose one of the most typical technical constraints encountered in delivering a software system: the integration of various components of the system without the introduction of defects or unintended consequences. In fact, project organizations typically allocate a third or more of the project time to release overhead – including integration, testing, fixing defects, and deployment – with the largest portion going to finding and fixing problems discovered during integration. When integration is the system constraint, TOC tells us that the most important focus for development teams should be removing this constraint.

Agile approaches to software development recommend the frequent delivery of working software to customers. When this recommendation is followed literally (software is released to end customers frequently), the integration constraint is regularly exposed and has to be confronted. One of the earliest agile approaches, Extreme Programming (XP), includes technical practices such as Test Driven Development and Continuous Integration that help make frequent releases practical. Continuous Delivery, which expands on these practices, has gained widespread favour as the agile approach which explicitly focuses on the integration constraint. In Continuous Delivery we find actionable advice on how to tackle the integration problem with techniques that scale across large networks of teams.

If everyone working on a system is trying to stabilize and improve the rate at which tested, integrated software is successfully released to end customers, then teams across the system will naturally have to work together and will find that their goals are compatible.
When the Constraint is Knowledge

More often than not, however, technical issues are not the biggest constraint in system development and the fundamental problem is not an integration problem, it is a design problem or a fitness-for-use problem. Far too often we end up with a system that doesn’t work well or is difficult to use. In this case, the biggest constraint in developing software systems is the way in which we decide what to build and parse that decision amongst the teams doing the work.

Organizations with an agile / lean mind-set would frame the problem differently. They are likely to identify the biggest barrier to making good decisions as incomplete knowledge, and thus the biggest constraint of the system would be the rate at which knowledge is generated. So a lean organization would focus on the feedback loop between customers and development teams. They would decrease the length of the feedback loop, increase the speed of the feedback loop, and remove barriers to the free flow of information inside the feedback loop. These organizations would say: If we can test our assumptions and designs more quickly we will learn faster and make better decisions.

Good Leaders set examples

Good and great leaders set examples on the following parameters: Help your team practice these elements to be able to scale and add value to themselves, product, organization and the customers:

Clarity – Eighty percent of success comes from being clear on who you are, what you believe in and what you want.

Competence – You can’t climb to the next rung on the ladder until you are excellent at what you do now.

Constraints – Eighty percent of all obstacles to success come from within. Find out what is constraining in you or your company and deal with it

Concentration – The ability to focus on one thing single-mindedly and see it through until it’s done takes more character than anything else.

Creativity – Flood your life with ideas from many sources. Creativity needs to be exercised like a muscle, if you don’t use it you’ll lose it.

Courage – Most in demand and least in supply, courage is the willingness to do the things you know are right

Continuous learning – Read, at the very least, one book a week on industry / sector / domain / business to keep you miles ahead of the competition. And just as you eat and bathe, organize your time so you spend 30 minutes a day exploring e-mail, sending messages, going through web sites, because like exercise, it’s the only way you can keep on top of technology. If you get away from it, you’ll lose your edge.

Triple Scrum Master – a Three in One Role

The old-fashioned scrum master would be limited to a thought process of getting the team more productivity, improve impediments, coaching the stakeholders on the value system of Scrum and so on … 

With the changing environment, the new demands of the customers and also the market, with the technology changing rapidly, the approach of Scrum Master should also change and adopt new ideas and be an evangelist thought leader and an idea generating machine. Having said all this does not mean nor am I endorsing the idea the role is to be done away or the earlier responsibilities are no longer needed, what I am proposing is taking the role to the next level of operations.

The new concept of 3 in 1 should be as follows:

Expect the Scrum Master to act and behave like a CEO for his / her projects, at times, the role would demand the nature of a CFO to be seen and finally the original job of a Scrum Master

I am sure all of us would be wondering what is this concept of CEO and CFO in the business of Scrum. As we say “Management has no role in Scrum, but Scrum Master is a management role”

I would and always like to consider a Project like a mini organization, which means that there would be a need to have CEO and CFO to manage the operations and costing of the project. With this understanding, I propose the triple role of CEO, CFO Cum Scrum Master for all our existing Scrum Masters.

It is a unique thought and may be a little ahead of its time in the market right now, but it is always important to be a trend setter rather than a follower of a best practice

Scrum Master in the shoes of the CEO

One needs to think at high strategic level for which the thinking process needs to change from the current behaviour patterns, The following would be the elements to practice and demonstrate:

As a CEO Scrum Master should:

The Multiplier Effect

  • Display the ability to energize people, Build a team of high energy professionals who would always play to win the game (read … Successful deliveries of sprint, adding business value to the customer)by choac
  • Translate complex business strategies into motivating goals and objectives
  • Make the team self-sustainable coaching the team and mentoring the individuals at regular intervals

Assume Responsibility

  • Display the ability to mobilise the organization, Work vertically and horizontally and diagonally with different stakeholders and establish credibility and respect from others
  • Understand the situation, take responsibility and respond quickly and effectively
  • Have a strong sense of ownership / passion and see things through till the very end
  • Have the ability to turn diversity into synergy, Synthesize the positive elements of each culture, gender and nationality, Be effective in cross culture and a multi-functional environment
  • Adapt to own style and approach as needed and required

Translate ideas into reality

  • Innovate, Execute and be decisive
  • Get ready to spark a change
  • Demonstrate ingenuity and creativity – think through ideas, build on them, display advocacy and gain buy-in
  • Develop innovative strategies that help build the team competitive edge and / or create the desired change and transformation
  • Encourage ‘Calculated risk’ – Foster a culture where people generate and implement new ideas

Display People centricity , empathy and listening

  • Listen deeply and objectively to what is said / unsaid and with an open mind , empathise and build trust
  • Proactively engage and collaborate with customers and partners to add value and create a winning partnership
  • Build a culture of constructive feedback. See out and act on both internal and external feedback. Give critical feedback in a polite manner

As a CFO Scrum Master should:

Think and Act with focus on profit

  • Manage elements for short and long terms
  • Identify and capitalize on opportunities to optimise resources, reduce cost, reduce waste and create sustainable value
  • Think like and investor
  • Drive higher financial results by improve the team performance, improving the quality of deliverables, maximizing the revenues (improvement in velocity)

As a Scrum Master, Scrum Master should:

  • Perform and conduct the role of the Scrum Master to the highest level as needed and demanded by the situation

By performing 3 different roles, the idea, is to expand the thought process and thinking approaches. The concept is not to wait for the results to come, but to create an approach, where results would be as per requirements.

Just like what we have a retrospective for the team at the end of each sprint, there needs to be a concept of Self-Retrospective performed by the Scrum Master of what he or she could have done differently and have the results behave in the manner and fashion as required.

There should be a regular forum in the organization for the Scrum Masters, where in they can come and discuss the issues and challenges in the system and seek ideas and opinion of other Scrum Master to see what can be applied from the learnings of others. It is great and a noble idea to learn from your own mistakes, but in the competitive world today to move forward , one needs to learn from the mistakes of others and ensure that we do not repeat them.

Let’s change the Phrase “History repeats itself”. It high time now !!!