Keep that Smile Going On...

Clouds fade away,

Keep that Smile Going On...

Problems get Solutions

Keep that Smile Going On...

Stress gets Relief

Keep that Smile Going On...

Strains leave you with time

Keep that Smile Going On...

Bad shows up to test your strength

Keep that Smile Going On...

Health improves with your care

Keep that Smile Going On...

Lives bring Lives

Keep that Smile Going On...

Breaks bring continuity

Sorrows bring Joy

Falls bring Rise

Shadows bring Shine

Losses gets you Wins

Keep that Smile Going On...

Old ways to New

Sun sets to Rise

Moon wanes to Shine

Keep that Smile Going On...

Life passes away

What you remain in photo is with a smile

Keep that Smile Going On...

Welcome new year with a Smile,

Happy New Year 2012!! :)

The day I saw Parliament worked like a team on a failed IT project

I couldn't hide my sad strained chuckle and hence the satirical take on what unfolded in Parliament on Lokpal debate on both houses.

IT as an industry is still learning from matured industries and best practices from various institutions set up earlier. Hence late nights, unrealistic deadlines, strained/stressed/harangued employees putting in multiple days without seeing sun set or rise, missing to understand stakeholders tacit needs, open scope leaving wide gaps to sneak in huge changes, vague terms and specs that are intrepreted multiple ways, training diverse teams that are recruited just before live critical periods in projects, constraints driven deliveries and relying on past sign offs to push through to unsatisfied clients, mis-understood and often introverted communications, are common traits across failed IT projects.

IT managers can now cite that even age-old institutions like Indian Parliament and a great marquee project for Government like Lokpal still failed to deliver a result for the same reasons above that fails IT projects.  

For IT, atleast, SCRUM and Agile has been a good blue pill to turnaround hopeless situation to see through a hope. May be Lokpal project team next time can follow SCRUM for

1. Talking to Stakeholders continously.

2.  Create a good backlog of issues and clauses required.

3.  Prioritize (Implement in Sprints).

4. Take incremental workable solutions and continue improving and implementing new features.

5. Retrospect at every sprint and SHARE and implement them.

 

Just rubbing in some free advice as if it is not in abundance. :)

  #Lokpal #sad  #Parliament

About New Look on learning practice

I was thinking why not apply Santa Red (not the exact hex, though) for my site and change its look for easy reading in this holiday season. Blogger had this dynamic view template and gives 5 different views to suit the reading personality types. It is easy for customization and blogger interface is really usable and gives a good time in customization of the template views.

Few things that are good in the new template are:

1. Easy to glance post titles and read what interests than move in.

2.  The searh really performs its function in blogger in this template well.

3. The reading experience is better. Gives for unobtrusive reading.

4. It is better for me and you as a reader to get related topics at a glance and jump between context linked posts.

 

What I want is your feedback. Are you happy with this shift? Can this style grow on you? Would this experience prompt you to visit my blog often ? Your feedback is important.  Do let me know.

Thank You and Happy Holidays!

Sprints as a Number or a Named Instance ?

Do you call your sprints as sprint 1, 2, ... or do you assign names to your sprint ?

This post shares my experiences and thoughts based on the various views that I have encountered with my teams.

1. Numbered Sprints are a great motivator. When you start saying Sprint 5, 9, 15, it really gives you the pleasure to know that earlier sprints had a successful closure. This itself motivates the team to conclude sprints with an actionable product and refer to the finished product at each sprint as proof of their capabilities.

Named Sprints are referencible and give a direction during the current sprint. The practice of code names for products under production comes from product manufacturing industry. The code names for Sprints orients the team and when talking instead of an arbitrary number. The name tends to bring about cohesiveness in teams, particularly when you are establishing sprint teams.

2. Numbered sprints become quite flexible as there are no boundaries established in the minds of stakeholders. Hence there are chances to add/modify priorities and user stories in sprints although SCRUM disallows this practice. It is difficult when stakeholders are new to SCRUM and wish to have many features in a single Sprint.

Named Sprints has potential to live up to the name and can ward off intrusions. Once the name of Sprint is decided with stakeholders, it kind of acts as a barrier for inserting more features that do not live upto the principle and Sprint Vision in the overall product vision.

3. Numbered Sprints are difficult to run in parellel. Again since numbers hold a sequence, stating that Sprints 3,4,5 are running with parellel teams, becomes cumbersome to manage and remembering the priorities of each.

Named sprints are good to align parellel sprints. I normally have a sprint called "libs and interfaces" that run in parellel to initial few sprints. It then makes it easy for me to have other sprint leads ask/discuss the features that can be a global library rather than reinventing the wheel within individual sprint teams. Thus  for effective architecture and design, named sprints become ideal for user story transfers.

4. Numbered sprints do not lend themselves to reporting well. For example, when comparing velocities and individual sprint team performances with stakeholders regarding complexities and user story completions vs iterations in sprints, it is difficult to visualize the working of the team.

In Named sprints, it is automatic to gauge the performance against the metric numbers as the names of the sprint and the numbers seemingly make a sense. I realized this because I use EVM for reporting. I initially used to report performance week wise, then tried to report it as Sprint numbers, but when speaking of numbers with respect to a phase/name of sprint, it is good to debate and understand the variances.

This is a matter of cultural taste and the SCRUM implementation maturity within your organization. To date, either of the projects (numbered sprints or named sprints) have been successful for me in aligning business goals to project results. So far, I do not have emperical evidence to prove if a numbering or naming sprints is good. May be few more experiments might yield some direction and shape up my personal preferences.

Has this topic been a concern in your work sphere? Is there a standard SCRUM terminology that needs to be adhered ? Are there any related experiences that you can share ? Looking forward for best practice evolution with collective intelligence.

Triadic Success: Why rule of 3 gives the maximum success

The impact of triadic success in our daily lives is something we cannot miss. The greatness of the rule is its simplicity. When we try to simplify a mantra/mission in 3 easy to remember phrases, it gives an immediate connection to comprehend, measure and communicate effectively.

The crux of the rule is the same as the spirit of the rule - "Be it an assignment or task or a desired result, make sure you split it into 3 distinct activities to complete it".  If any result is achieved because of a 3 steps process/procedure, the impact is bound to be great and the potential maximum.

Consider the following cases that elucidate the success of finishing a task as a set of 3 activities.

1. Managing a delivery/milestone -  Plan/Revise, Execute/Follow up,Communicate/Market are keys to get appreciation and satisfaction of a job well done.

2. Writing an email -  Draft/Read, Review/Act, Follow up with a call/confirm makes us sure there are no slip ups or errors in communication. Similarly for any communication it is important to use auxillary medium to reinforce the main message in the primary medium in which it was delivered.

3. Creating a storyboard - Ideate, Visualize, Doodle/Explain when done in 3 distinct phases results in a good output.

4. Writing a Blog - Ideate, Research/Draft, Revise/Publish gets you to do your writing exercise continous than leave it mid way and does not consume enormous efforts.

5. Travelling/Holiday - Evaluate options/deals :), bookings/arrangements, pre-checks/post-checks makes a travel or a holiday trip wonderful experience.

6. Writing a problem statement or a mission mantra - Try creating a group of familiar rhyming phrases (something like 3 R, 3A or 3S rules), it is bound to resonate better and easy to discuss without complicated charts/presentations.

7. Health and Time Management - Start on Time, Allocate Time for important duties, Execute them in the slotted time is what many time management experts speak and elucidate in various ways. In fact this is the best way that I practiced for Gym routine in my schooling days even during life-changing examinations. 

And list can go on.... Hope you get the picture.You may wish to identify and add Triadic rules in what ever you do with little thinking and efforts.The criticality of applying this rule in every work - personal, professional, social requires concious identification of its play. Have tried to compose this topic as to what is it in this power/group of 3 that is so magical yet elusive.Any better way you could help me rewrite the same post is welcome. :)

Funny Fact of Change

We always resist change when it comes to our lives. But when we seek it out, we are happy with the results.

Be it an organization or team restructuring, a new face of life (new location, new house), we tend to attach it with us if we seek it out or are in drivers seat. If it is done at behest, we tend to squirm and wiggle uncomfortably to move and adapt. In these zones, we tend to be on our own to seek the change.

This paradigm taught me few lessons on how to handle change.

1. Germinate a change organically. Keep creating the need till it is felt. Try placing stories on how current situation is screwing us up. What problems needs change to make our lives better (if only some one can get it done).

2. Readying for change is important yet difficult than realizing and rolling out change: Most of us are receptors of change. We are treated as passive adopters. We are considered to switch ourselves as it is wired to react most often than act upon. This kind of works in production factory setup. However, later generations have figured out that getting unions on side of changes makes for better execution.

3. Fears rule when reflection for change: When we get an opportunity to comment on what the change means to you, we are at creative best to bring out all black hat thinking to fore. We can predict and provide for enough reasons on the pitfalls if executed.

Now, this is a good thing as opposed to labeling them as laggards or cynicists or a critic. Stereotyping is a major error of leaders and managers at highest level.

Why is it then that these are not elicited during planning phase and we rely on change as a risk to take chances on the workings of change ?

Importance of Sprint Retrospective: Distinguish between Repetitive practices vs Best practices

When you see or hear a case that seems to resonate with your past experience, we are often prejudiced to state that we have seen similar case in past and that we overcame it with a certain solution and a way. We tend to repeat that again.

This is wrong premise and is a classic case of perceptual error. Often than not, it results in a sub-optimal working condition.

It is really important to repeat only the best practice and not repeat a practice that worked earlier. This is where project retrospectives help.

Project/Sprint Retrospectives help identify as to what we did, how it worked, what are the best aspects of the practice that should be carried forward, what can be improved in the current system and then document them as a best practice. What ever worked well in a given transaction is recognized for a spot reward, but is not essentially disseminated via the global knowledge board in intranet.

email Templates is a classic example to explain best vs repetitive practices. In my projects, we first decide on the formats of email for various regular communication areas - status reporting, Budget (efforts, cost) allocation, work pull from Kanban, issues/dependencies attention, etc.What we do is decide how we would craft the subject line, how the messages will contain the key information and what are ideal time to expect these emails. This way, when ever we are in a meeting (daily standup) or my meeting with management stakeholders and clients, it is easy for search and finding the relevant emails. With the mind tuning to see the key points in familiar areas, it is easy to be efficient.

While these templates are by themselves a good practice, we have realized that the formats of emails that worked in one project needs improvization based on sprint team understanding, comfort and ease before adopting it in next project. Hence we have a best practice to have email templates, but we distinguish it and do not  repeat the formats from one project to another.

This way, we not only innovate and explore better, we develop a keen sense of intuition as to what works and what is a value-add in a given constraint, situation or culture.

Does your retrospective allow for discussion in identifying the repetitive vs best practices ?

Thank you Steve

A sad day to start Vijayadasami. It is a day where in India, people initiate kids into life long learning. Ironic that #steve chose to part on same day whom many of us look upto be a professional like him.

Thank You #steve. I am  among countless millions whom you have influenced by everything you are known about.

 

Your speech of "Stay Hungry Stay Foolish" was instrumental in kicking up my entrepreneurial thoughts.

Your stage demeanour and the articles about how you practice for it and the flawless performance although non-imitatable have been a worthy benchmark to look upto.

The few negatives about your attitude and sticking to your ways that came out in publishing domain only reinforced to me that attitude is a good thing.

 

.You have done so much for an unknown mentee by your public profile.

Just imagining how much you must have taught people who had the ability to work for you and could have observed you. 

For an unknown person from India, you cared to be a role model, mentor, influencer and a idealogue to be the best in what we are.

 #sad #tears #prayers #steve jobs

Capacity Planning vs Capability Planning : How Agile changes Project Management

Traditional PM world starts with capacity planning exercise. Key questions revolve around "How much or How Many". The view point from industrial age is that build capacity and it should take care of building and executing deliveries only limited by capacity constraints. Capabilities are expected to be built inside and hence are not mainstream planning tool.

However, our own experiences and stats about project failures gives the message that there are inherent flaws in this model.

Why not, then, acquire, plan, protect and prioritize capability planning continuously to run the shop. This flip in thinking has dramatic consequences.

1. The key question that gets answered is "What is needed" vs "how many are required." The requirements are filled just in time, so that relevancy of skills to job is highly improved.
2. The Capabilities to execute the available capacity gets the attention thereby enabling larger throughput and increasing efficiencies.
3. Managing Capabilities establishes mature HR processes and seasoned managers who are task and vision oriented than handling capacities which is an administrative overhead. 
4. Encouraging thinking about building capabilties positions you for a competitive advantage. Building capacity is not a guarantee of success as capacity can lay under used, mis-used, or un utilized and what "Goal", TPS, DELL ways of working have taught us.
5. Focus on capabilities keeps you ahead of the pack in quality and leading industry on your terms. You are now able to be nimble, agile and helpful to add Just in Time capabilities than being constrained to use the available resources from an old capacity pool.
6. Capable resources create an innovative environment while just planning for capacity and filling in positions promote laziness and status quo.

SCRUM teams add capabilities while Sprints pull up the required capabilities to deliver a Sprint.

Seemingly risks are higher to focus on capabilities than planning for capacities and filling in capabilities,  but it is counter intuition that works in this case. 

Try it and let me know the challenges you had with Agile recruitments and how you improved your worksphere.

My Dad's advice

Well, there were lots. Do this, Don't do this. Do this way, Do I beat you to make you listen (yea, it is allowed in India).

Every step of childhood was a judgmental one. However this is different.  

"Do anything with discipline of time and with your full presence. That will be your recognition and your brand". 

How true...

Be it in office: People judge us by the time we make entry and exit time from office, Timing Phone calls, Discussions, Reaching time for meetings, Break timings, all done with a discipline of time really makes people know you better.

Be it in social circles: Time of publishing our tweets, facebook updates, blog posts publishings, hang out with friends, all done with discipline of time really makes your friends look forward to meeting with you. Remember weekly get togethers at a given place and time and how we are eager to get there ?

Be it personal: Time to wife, parents, children, and self – exercise, reflection, thinking, reading all done with discipline of time makes us crave the moments than a haphazard way of spending time multiple ways.

Remember, what we SMS, say with fondness and sublimity, passion and twinkle, to our friends, family and close acquaintances: "I had a great time."/ "I look forward to the times". / "I remember the time…" / “Would want to have those moments back...”

In everything, we remember the time as the primary context and fix the incidents to recall within the context. The incidents that happened in that time are so memorable.

Every time , I realize the statement to be an eternal truth and has a sub-conscious effect on me whenever I get this right. In hindsight, more than achievement, it is satisfaction of a complete day and always ends up on a positive note.

Thanks Dad! Love you!

Agile findability: Use of Concept Maps for Revise, Reconstruct and Resume from Problems

De-construction of a system into its constituent parts to study the underlying problem of parts and prescribe fixes has these days been devoured as a bad idea. The basic premise of these arguments is that while individual parts work in a whole system, there are interfaces, handshakes and undercurrents that bind the parts together to function better as a whole.

This is true. But I don't agree that deconstruction is a bad idea. Initial practitioners, start with Root Cause Analysis by deconstructing the problems into parts and mostly report the findings using a fish bone diagram. Lot of us taste initial success with this method of studying parts and applying solutions to the systems.

However, stopping here means you lose the plot when you enter solving realms of complexity something like relationships and interactions with people, systems, groups, communities, projects, clients etc. While deconstructing these systems, we always need to

1. Connect and construct them to the source(s).
2. Always seek to find sources (as problems are inherently complex because of not a single lead, but because it has built up over time in multiple occasions).
3. Investigate how these parts enabled/disabled others functions in the system or discover the objectives for which the individuals and independent resources were integrated.
4. Determine the crucial factors among the canvas that needs to be leveraged better to set right actions.

This is where applying Agile principles, we could see a better problem solving approach. To apply the Agile findability of “Revise, Reconstruct and Resume”from problems, I am going to introduce you to a new thinking and software tool that enables a better approach to fix complex problems.

Concept maps provide much better insights into problem solving techniques. Google for the term and you could learn from articles that suit your reading styles. For this post, I refer to CMAP or VUE ways of using concept maps. I highly recommend downloading both of them and you could be on your way to solve complicated problems by uncovering relationships, the troubles, weaknesses in the links and exposing them solves the problems.

Revise:
Rather than asking "How did we come to this stage", it is better to ask "What all contributed to this snap". Answering the question then lays emphasis on all connected and unconnected incidents (individuals and interactions in Agile terms) and using any of the concept map tools lay them on a timeline.Using prepositions to illustrate the connections and showing the multiple tracks in a timeline, problem solvers can evaluate the entire map and take a holistic relationship view of the problems depth and solutions at hand.

In many incidents involving people, bringing the connections and non-connections(people not in loop) out is the critical step. Once the information is in public domain, solutions emerge and the problems get solved in a much better fashion than forcing one with own prejudices and perceptions.

Reconstruct:
While you draw concept maps, make sure you use prepositions to explain the link between nodes. The standard connections and often missing lines (floating nodes) are the sources of the crisis. Reconstructing the lines and visualizing how the links could have been better between entities (nodes in concept maps) gives multiple solution threads to approach a given situation.

Lay emphasis to links and the phrases that determine the relationships. Treat multiple nodes and their linking branches as factors that influences a particular node (Responding to Change vs following a Plan). You are now better prepared to learn from mistakes and make them better by leveraging the factors to turn them to your advantage.

Resume:
Going back in time to the step that is right is not an option and never a great step. We desire to rewind and start again from where things were right. Hardly this is going to guarantee that problems vanish. Alternately changed equations will force a new set of problems at our hand.
Hence it is important to lay the solution options as a separate concept map on table and see the multiple tasks and confidence building measures from where the links can be strengthened, not only for current job but lay a stronger and confident foundation for future relationships (customer collaboration vs contract negotiation).

After few years of practice, am sure these connections can run in your head and you are the best troubleshooter, deal maker and most effective relationship manager for your organization.

Let me know your disagreements and we can have an interesting discussion :)

EVM Model for reporting SCRUM projects - Introduction

SCRUM is a good operations model. While many consider it as a project management approach, often it is realized that SCRUM lacked lingo for reporting business performance.

As of date, Businesses and projects leaders do not care much for project execution or delivery models. Hence they do not care if we do it SCRUM way or not. Thus SCRUM practitioners and Managers have this bridge to cross so that SCRUM gets main stream.

Business and Project Leaders ask for 3 main measures to be on top of project and enables them for better decision making irrespective of operation models.

1. Am I getting the value for what I spend?

2. Do I know how long and how much it will take to close the project under current conditions?

3. Can I claim with reasonable confidence that project goals will be met successfully and drive my company to be successful?

These measures are available in EVM and hence it is a natural fit for SCRUM projects to associate the EVM lingo in the framework.

Also the concept of Earned Value in EVM benefits more from SCRUM way of delivering sprints.

Before we dive into the working, here is a comparison on fitment and adaptability between SCRUM and EVM.

S.No	SCRUM Phases	EVM measurement Terms
1	Project Planning, Product Backlog Planning, Product Vision	Budget At Completion
2	Sprint Planning	Planned Value
3	Sprint Progress	Actual Cost
4	Sprint in progress	Schedule Performance Index, Cost Performance Index
5	Sprint Retrospective	Earned Value, Sprint Performance Index, Variance at Completion
6	Sprint in progress, Sprint Retrospective	Cost Variance, Schedule Variance
7	Sprint Retrospective (Using Sprint Burn Down chart)	Estimate AT Completion / Estimate TO Completion
8	Features/User Stories Burn up chart	Cost Performance Index

Related articles by Zemanta:

• Scrum Methodology: Coordinating Teams to Produce Quality Products
• Scrum guide 2011
• Earned Value Analysis - What is it? Why do I need it? How do I do it?

Happy Teachers Day

For all that learned
For all that shared
For all the provocations
For all the thoughts

For the prods and Nudges
For the Talks and Reflections
For the Moods and Perspectives
For the beats and bash

For sharing the experiences
For kicking the brainstorms
For listening to the reels
For hearing the spiels

With the comments
With the tweets
With the wall posts

The encouragement of all
The time of togetherness
The collection of intelligence
Comes the Wisdom, Learnings

You, my friend,
is my life long teacher.

This needs a special day to wish
and here it is...

Happy Teachers Day!!!

via ScribeFire

SCRUM Survival - Key Mistakes in Initial Change of Guard

If you are an initiator:
1. Do not make the mistake of saying "We do not need project managers" and "SCRUM Masters are there to replace them".

2. Do not bring in a critical project to showcase benefits of SCRUM. Odds for gaining buy-in are always remote. It will be relegated to a one time wonder or considered an extreme measure. In critical projects, only people and results are spoken well, not the process or the way it was done. So never pick a critical or riskier project for SCRUM adoption. You are never going to get it past this one project.

3. SCRUM is meant for projects where details can evolve, but not the requirements, design or end solution. Do not make the mistake of saying "Since we are following Agile, you can keep giving new requirements in every Sprint". In SCRUM there is a need for Project/Product vision, define technologies, architecture, have a blueprint ready and all requirements planned for sprints in advance. It is only the details that can evolve, not the requirements. NOTE that evolving requirements projects will fail neverthless if it is SCRUM or not.

4. Sprints are not discrete events. They need to be continous. One of the anti patterns of SCRUM initiation is to conduct a sprint or couple of sprints, then evaluate that it is not working. Or pace out time gap between 2 Sprints. As with 10,000 hour rule, you need minimum of 10 Sprints or roughly 30 weeks to evaluate goodness of SCRUM and it needs to be analogous.

5. Reducing Retrospective to a paper process and not learning from it: I renamed them as "Refreshpectives" in my implementation. Somehow, to me, retrospective conveys meaning of just analysis and historical value. Refreshpective to me gives more meaning that you refresh what happenned and DONT REPEAT what was not correct. SCRUMs or subsequent Sprints suffer from mental blocks and tunnel visioning if Refreshpectives are not conducted in open environment and learnings are not taken ahead.

6. Managers - Please dont delegate your tasks in name of Agile. Reporting, task allocation, project planning, risk planning, mitigation, margins, allocation are all still your job- your deliverables. A SCRUM Master and SCRUM teams can only help you in thought process and assist in giving inputs to performing the role. My first SCRUM implementation sufferred when manager went hands free of the responsibilities and retained more of an administrative role only. SCRUM Masters are hands on and are quick in tuning velocity needs to meet plans. Treat SCRUM Masters as navigators (Velocity Managers) and SCRUM teams are drivers (taking you to the destination). The project charter still is your responsibility, dear Manager.

To Developers:
1. Understand that you should now think modular. No longer quick codes that handle a job piece as stand alone program are going to work. While thinking, ensure you follow a modular structure. Think what pieces could be converted as a lib file, what could get into config file, what needs to be a third party extension, how you would create hooks, interfaces to move them further and how you could split the source code into multiple files in src folder.

2. Make sure you always make provision for 35% effect. 35% of your code will be tranformed - either scrapped or rewritten or extended or reused. Think and Design every code for this 35% rule. And this is critical to success of Sprints.

3. Estimate time including scrap value. This is why Sprints and SCRUM estimations are good. Since they are done by team members who are going to work, you can factor in time to experiement with your ideas for some time.

4. Think Design first. Papers and Pencils are still the best form to release creativity. Agile, atleast in SCRUM context doesn't mean you jump in to code directly. In fact, it is opposite to this thinking sense. Design, Paper craft your story, divide and define your tasks and then take up finishing a user story.

5. Do not assume or expect Product Owners to be techies. In fact as a product owner, the job is to define the vision, goal and the working way for a user. You, as a developer needs to help product owner visualize how it will look at end. Not the other way around.

6. Escalate. SCRUM Masters and Product Owners and even your peers are humans. They are bound to make errors. Own the stand up meeting room to yourself. Make sure you articulate the allocated story well. Ask your peers for impacts in their code. Check if there are dependencies. I have seen 2 kinds of stand up - One where SCRUM Master speaks most of time. Another where designers and developers speak their mind. You can guess which would be the most fun.

To Onlookers:

1. Support SCRUM, even if you dont understand it. You are making the environment more greener. ;)

2. Read Agile Manifesto.

3. Reflect and embrace change as constant. Controls and Measures no longer work. Measure only what is done, not fit measurement to what was designed.

4. Visualize: Figure out the ways how SCRUM would have tackled your problem. Visualizing SCRUM implementation or for that matter any process, will make you more resilient to make the transition against heavy odds.

SCRUM Survival - Need for SCRUM Evangelists

If you are like me who believe SCRUM not only will solve the current project problems but also give a good and sound structure for building a high performance team and you are the first proponents in your team/organization, Read On....

SCRUM way of working requires a "cultural" change. It, hence requires mindset change, belief in common sense that at times are counter intuitive, letting go of control and living always in middle of collaborating and democratizing decision making and importantly needs backing of the entire organization structure to support it.

SCRUM is not a start and stop application. It requires calibration till the "cultural adaptation" meets Agile goals as per the SCRUM framework and enables you to achieve results quickly, with all round satisfaction and happiness.

How do you initiate SCRUM in your organization ? How well and how much do you require to sustain it ? When do you have to push SCRUM mainstream ? How do you address skeptics, fence sitters and passive supporters ? Where does the critical mass lie ? When can a SCRUM implementation move beyond "you" to a culture that you have enabled multiple evangelists?

The series of blog posts seeks to address these burning desires. Some of the points in these posts will show a bias towards my personal thoughts and tribulations in my trial runs by fire with one and only belief that

"SCRUM is a GREAT philosophy to execute WELL-RUN projects"

Part 1: Need for a SCRUM Evangelist:
SCRUM literature does not speak about it. The belief is that roles in SCRUM would be their own evangelists. However in practice, it is important to seek one. Here is a first pitch job description of a SCRUM Evangelist.

Adapt:
1. Must believe and understand the Agile Manifesto. Important to repeat it atleast once a day. Speak about it in meetings when resolving decisions and issues.
2. Must be a signatory to the "declaration of inter-dependence"
3. First should be able to learn to adapt and then to introduce rules. Have seen SCRUM Masters come in and say, we do not need Project Managers. First death knell for any initiative is to remotely associate and introduce insecurity in workplace in taking an initiative.

Amend:
4. Can demonstrate ability to resist temptations to

4.1 Move back to old ways of working.
4.2 Being dogmatic about SCRUM rules and thereby be inflexible

5. Fearless for loss of job, failure and share success. SCRUM Evangelist must be driven by motive and attempts made with every learning to make SCRUM successful for future benefits.
6. Should be a prolific writer who can identify success stories and propogate them with tying in relationships to SCRUM methodologies through presentations and articles.
7. Make sure to customize SCRUM over and above SCRUM mandated policies. It is required. SCRUM may not answer say the budgetary spends or for that matter, the remaining time to completion vs the time a story is dormant in a queue. (Burndown charts have their own limitation).

Associate:
8. Should be a person who does not rely on tools and does manual work, if necessary multiple times. Start with available tools (Excel, Paper, Charts, Post Its, etc). Then introduce tools that make more sense to the culture.
9. Must be a person who can think "culture" and not "process"
10. Conduct Retrospectives and document and share learnings across teams.
11. Constantly speak the SCRUM lingo for any reference to make people imbibe the SCRUM way of working.
12. Should be able to build a name-product association with SCRUM. Think Agile, SCRUM, Think "You" the evangelist.

How else have you evangelised and introduced SCRUM in your organization ?

Achieving Results

Where there is the right blend of tools (could be a process, people, product, intermediate outputs/raw materials), there is an easier way to achieve the results. Relying on alternatives and adjusting work styles to suit a tool  is one side of the equation. Creating and owning your own tools is the other better side. This has a far greater productive quotient for both you and achieving results with aplomb.

The tools that are part of the work "culture" and does not force limitations on styles of working, gets better and better with usage, observation and evolution. Thus, a sense of belonging, togetherness, and shared passion evolves in business and relationships alike with networks, community and ambassadors around the "tools". People who have converged on this one "tool", getting together and demonstrating more similar thoughts in other areas amplifies the network effects of spreading good words and work alike. Many from this one group could be related in more ways with other products, company, industry, social media, tools, etc.

When such communities get together to accomplish a result, the communities of practice become a self-sustaining organization breaking the barriers of time and space.

Develop support systems to build your core

If you want to be a great manager, you cannot acheive greatness by focussing on getting management theories right. Rather if you focus on another area that is your ally - either estimation, troubleshooting, solutioning, reporting, communication or coaching people and bring in management tasks to work with your key strength, the chances for management greatness is likely.

If you need to be a great parent, it doesn't matter if you give them what they want or support in every all the time. Rather working on making them get it with right means and helping them overcome themselves will make them remember you fondly. It does matter for them when the time is qualitative and there is an element of learnability for them. 

If you need to be a good developer, then it doesn't matter if you remember syntax and code and master programming languages and tools. You do get a chance towards greatness if you can develop business mapping to technology abilities and choose the right fit  and deliver them.

If you need to be a trainer, practicing platform speeches, stage manners, crowd controlling etiquettes and rigors of training elements will not get you good satisfaction scores. However, if you are a good listener and share how you learn and show keenness to listen genuinely, then more than the subjects that are taught, we will know the key takeaways better. We have experienced this with the teachers we like. The subjects come naturally to us because we like them and find them great.

If you want to be known as talent manager, it is not just hiring experts and spotting experience that will get you the name. Instead finding fresh talent and grooming them for future will get you the recognition.

In every sphere, it is not the core that should alone be the focus. If it becomes the sole focus, then you get to be the weakling. Imagine a manager who manages and delivers projects successfully but is a bully with team members and is narrow in looking at profits from client relationships, a parent who always controls the child to do exactly the way they wish to see them perform or supports all small excesses, a developer who cannot write or speak their understanding, or a coach who believes in speaking all the time. These are the problems of being excessive at core and forgetting to develop their own support systems. No wonder all of them are good at their work and we need them all the time. But from personal standpoint, there isn't much to gain.

The core needs support and development from the external systems to elevate the spirit of core. Concentrate on how you can build and develop the core with association of support to provide for all-rounded greatness.

Agile Project Management and Communities of Practice

Reading literature on communities of practice, I was able to synthesize my earlier reading of book Presence and find its relevance in my application with Agile teams that I currently manage. The concept in the book and in communities of practice, reminded me of a key component of success - Learning is fun only when you are in presence of a peer group that is determined to succeed and evolve, as much you wish to grow yourselves by doing it together.

Community over Self is how people claim that goodness prevails.Invoking the altruism in the statement sets a lofty goal that many want to miss in a goal-oriented,capitalist world. Community with self is a better promotion and hall mark for all great accomplishments. Coz in every accomplishment,  social good elevates the self and hence a greater good is accomplished. Take example of project teams. While every one accomplishments are bound to be exemplary, it is the collective deliveries that make the success sound sweet.

In Traditional empirical model of management, there are lesser known contributors and few go beyond call of duty. This is because of control-command structure that resides with manager planning and assigning tasks. Ownerships aren't collective. Finding a piece of work and judging its priority and executing it is a self-organizing team's strength. This is what communities of practice do. Since there is ownership in center of the team's existence and the getting together is voluntary, working together differs from a transient loosely assembled Just-In-Time project teams. Thus contributions come from every one and each of them enhance it to levels set by their peers in an automated fashion.

This is aptly captured in Declaration of Inter-dependence manifesto that is foundation of Agile Project Management.

via ScribeFire

5 major mistakes I did in my SCRUM project

1. Did not contain the length of Backlog items:
 I allowed it to expand. While backlog can be stretched and it can theoretically expand to infinity, it is a real bad idea.
This means that project planning did not factor in the schedules or was deferred to later stages of the project to accomodate moving targets based on users requests.

Although a subset alone needs to be taken in Sprint, the inter-dependencies between feature sets and integration challenges with mounting scope always carry the mine to derail the project. Easier to understand, but it took me a beating to realize the importance.

2. Pile up Ahead in Queue: While fresh development was executed in Sprints well, it all piled up ahead in queue in review-fixes stage. This Sprint is where all problems originated.

In my project, there are 4 dependent stages where reviews are done by clients and vendors. While we executed a batch and delivered it to the review stage, in interest of time, we moved into a fresh Sprint, than waiting for review cycles to complete. Thus a Sprint was defined till a review stage. The issues in earlier sprints started coming in during reviews and some had a global impact. When we took the fixes in a separate sprint, the length of that Sprint backlog became high (due to a combination of multiple sprints) that it slowed down the project progress considerably.

Thus final closure got delayed till all dependencies were cleared across all the deliveries in earlier Sprints.

3. Bring in more people in middle of Sprint: 2 new resources were brought in the middle of sprint and they were expected to test the features based on understood logic and functionalities. With no background, they let issues pass through to the deliveries. These issues then extended the Sprint thereby affecting start of other Sprints.

In the end, the timelines of the project had to be shifted before final deliveries started to happen.

4.  Did not enforce sign offs and Prioritization at start of Sprint: Well, this was done at an informal level. But closure of a Sprint through Sprint reviews and Retrospectives, didn't happen formally. This led to a major escalation, that was then brought under control.

5. Clients and Vendors were not fully in SCRUM Wagon: While we pulled in SCRUM practices and principles, the roles of clients and vendors and their roles within the SCRUM project weren't fully articulated. We had their buy-in for sure. While Agile and SCRUM presented a good development picture and initially worked well for shorter deliveries and near to final shippable products till the control was with us, the complete cycle was not implemented within the SCRUM vocabulary (like Sprint Planning, Sprint Reviews, Sprint Retrospectives, etc) involving all stakeholders from clients and vendors alike. There wasn't an issue with this, but may be if this would been practiced, the schedules, efforts and planning would have become an easier affair.

Did I screw up my SCRUM project. No. It is just that these didn't work well or that they weren't done as prescribed.
May be call it a "Theories vs Practice", "Knowledge vs Experience" or "Go by Book vs Customize for the needs" paradox in which these issues got uncovered.

A lot wiser and a lot less inhibition in going with my next SCRUM implementation .

 

via ScribeFire

Submission is not Subduence

When you apologise or accept a bad, it is submission to the fact that given a possibility, you could have changed it. This is possible when you are conscious of your actions. This is the phase where your growth is unhindered, because you know the result of an action and you are malleable to amends. You wish to make a statement that you were given the right to choose and you own the right and wrong in decision or action. In the particular case, the fact states that you could have made it better and you accept it, often sad but yet as a experience to not repeat.

Subduence is executing others wishes. You are handed a checklist and asked to comply. You have a choice or opinion, but the way is chosen. You are either in or out. When freewill is passed over to a note that demands action according to set wishes, you do not allow yourself to submission. In essence, you have lost what you could have owned.

Submission allows amends, Subduence is rigid. In long term subduence allows you to carry on with your current life. Submission allows you a change of course. Be concious and you can never be subdued, EVER.

Touching the Ground

In hindu culture, it is a habit and practice to touch the feet and ground of elders and in front of gods.  Traditionally, this is an enforced rule. But in reality, it teaches you an important lesson - Being grounded to realities irrespective of the heights you reach.

In Managers too, this needs to be an enforced trait. I recently was struggling to find words explaining the role of an Instruction Designer to a senior manager. The commentary was how and why we cannot use fresh talent from college to analyze content and write them up. It was difficult conversation.

Today, I realized that may be, I being aloof from the ground is not helping matters. So under the able guidance of my senior most ID, I requested to be mentored in writing an existing storyboard. Not that I came out trumps from the exercise, but I got enough words to express the travails and troughs a designer needs to go through to get a great learning flow and seamless understanding of content.

Touching the ground this time wasn't a conscious exercise. But it is good to add to my arsenal at least once a year to be hands on with tools and techniques used by the team working with you.

Mentor-Mentee Relationships: Value in Gurukul way of teaching

I was watching Karate Kid movie. In it, Jackie Chan as tutor would advice the kid to do a repetitive act for months together. And he chose the act based on the kids bad behaviour observed casually in the kids default habitat. When the kid gets fed up and decides to leave that he is not learning anything new and feels there is no karate lessons in it, the master opens up the Karate lessons. Teaching the kid that the basic good act and discipline to do them is the first lesson.

This is how Indian mythological stories talk about gurukul students doing lots of daily chores and helping the master and their family before they are inducted to main stream teaching. It serves as a filter for the teachers to decide the dedication, respect and above all the implicit confidence and obedience in the wards before they attain the worthiness for being taught.  This process of induction takes years for a ward to attain studentship rights. The conditions of learning are tough and the acclimatization to the toughness and rigor of daily discipline is the first lesson for wards to master before proceeding further. 

In corporate mentor-mentee, this is a crucial lesson. The lessons, I come to value in this system is that in any mentee, ego, attitude and prior experiences needs to be broken apart first. The way the mentees take this first step decides the investment that mentors wish to allocate to the mentees. Many a times mentees will feel that they are being abused in the model and decide to leave. Mentor and Menteeship is build on relationship of trust and implicit obedience. So filtering out in first step is an essential way to allow for the correct combination of Mentors with Mentees.

This is not to say that there could be mentors who would misappropriate and misuse the system and mentees mental state. Good mentors like good teachers are rare. It is to spend time in evaluating the quality of mentorship in the individual and investing reasonable time is the only way to evaluate and find the right mentor. The true quality of a mentee is to search for a right mentor and then place their trust and obedience in doing exactly what the mentors decide and want you to do. Even in gurukul system, wards move from one teacher to another to seek out special skills that they wish to learn and gain from different experience.

Real learning is self-inflicted and happens in silence. What mentors traditionally do is to allow for conditioning the mind, heart and attitude to be tuned for learning from the surroundings. That is also the way gurukul teaching is structured. It is always the ward who completes their study and question the teacher for clarifying the doubts. In effect, the mentees should seek out the mentor and not wait for the mentor to keep a check on the progress.

Egos, Attitudes, Misplaced self notions, Peer and Self conceived importance that block the mental state of learning are all what corporate culture provides to an individual. True and great mentors take the burden to break them down and make mentees humble enough so that learnings can seep through them. The osmosis of learning is what teachers and mentors expand and clean up for a mentee. Rest is self-discovery and getting required exposure that Mentors seek to provide to their mentees to test out their hypothesis in real life.

 I am lucky for getting Mentors early in my career. One sign of a true mentor that I had was they used to gift and initiate with a book. This shows the caring and the attitude to take me under their stewardship to groom me further.  I still look up their tweets and blogs to learn and assimilate their thoughts.  Process of seeking mentor is itself a great experience. Start out on the path for a great learning and career.

Creatives

When something is not right, the proposed plan is not going to work, the management decisions are slit and drowned in the throats, the first signs of revolt will be from creatives. The pen-down strikes is famous and will be in the form of key thought provocators to leave for greener pastures than to fight a battle losing their age and time in what could be used in more fruitful creative pursuits.

Creative people are not ones who always start from clean canvas and start from scratch. Nor are creatives who always yearn to create everything new everytime. That is a bad attribute and such individuals never can get close to being a creative. Creatives are an inspired gang who go beyond social prophecies and exist to live for their spirits and create their self satisfaction boundaries. The boundaries that are truly personal. It is not that they do not need social attention (as in Maslow social layer). Their cravings are for their belonging within environment that allows them to contribute their own ways. Creatives find places more viable where they can take up existing chaos and are able to thrive in seeing the path within.

Organizations looking at managing Human Capital programs for creatives need to go beyond compensation, training programs and creating their growth paths towards creating opportunities for networking, interactions and empowering them with resources to allow the creatives to explore themselves.

Creatives need empowering managers.Managers who allow 360 degrees freedom to move themselves around as long as ideas, thoughts and deliverables are harmonious in existence within an individual. This is because creatives are self-managed with their time, are conscious of the efforts and are controlled in executing their ideas. Creatives look towards shipping their work often and are eager lot in seeking feedback. Hence managers practicing frequent positive toned feedback and holisitic examples towards honing their character is a desired way for managing creatives. Many times, managers give feedback for homogenizing creatives within their groups for ease of appraisals. This works against creatives in continuing their work.

Creatives are idea fountains who don't pass on fads and jump into every visible opportunity. They need time to sink and sync up with relative environments. When they take the first step and mind it, it shouldn't be a management mandate, they are sure to see it to their fructification.

"Half creatives" look up and around for taking up their work and seeing it executed by others. But it is not the completely developed individual who has the creative abilities to network, seek, inspire, work around and get their desired results. Self and all-round developed creatives always and always will be the first to see their results. It is an insult to present their ideas to them and make them a second recipient.

Creatives are inspired by work. Not that they need to see their titles and select the work that is assigned in their job description. Creatives job description is simple: Get the job done. Run till the last mile. Seek and see the satisfaction and glee in the customer.

Are you a creative ?

Be Cranky, be Bold, be Risky: Digress to Initiate is a success habit

Often, I had realized (thanks to my boss for pointing it out) that the team which signs up for a bold new initiative or idea, digresses a bit to get the mojo to make the initiative a success. I deliberately follow what my mentors taught me: "Be cranky, be bold, be risky". It was too personal a learning that I didn't pass it along. But when I observed my teams who are ready to take up new ventures, I realized that they have taken these lessons onto themselves.

Be it a new productivity tool, a process change initiative, a team wide initiative like Knowledge Management, a New Product Implementation, an over-committed project, deadlines that are in past, initiative takers do not follow the path of management, existing processes or rules of organization. They need to digress, they need to create fun, they want to find  doing something out of realm, each one have to find out the personal connection, and they need to reinvent new methods for the initiative to succeed.

While lots of books have been written on how innovations, new products happen with top-down evangelism and many celebrated failures before a great hit and a sustainable model is evolved, I think often overlooked fact is how many times digressions has taken place by individuals and how it helps initiatives thrive in organizations and particularly when it is driven bottom-up and has created blue-oceans across industries.

At least my team seems to find their mojo from this and hence almost any new initiative often has a tangible and good end signalling start of a new phase. How has initiatives been shaping in your workplace ?

Confidence and discomfort for better Thinking

Once we know we are on the path free of traffic, we put on cruise control and hold the steering wheel just to navigate.
This is comfort zone that devours us from thinking and is boring to our spirits. We are controlled with a switch and no longer live our way.

In traffic, we get uncomfortable, navigate our way, think to get our way out faster, change gears, calculate probabilities of lanes for fast movement and importantly make choices all the time.

In both instances, we are confident of our riding abilities. It is just that thinking, evaluating choices  and making decisions, makes us alert, responsible and responsive in uncomfortable situations. It is in making continous decisions and evaluations that allows every one in traffic to bring out their best abilities to get their way faster.

Hence it is confidence and discomfort that makes us agile and better professionals than use confidence to slip in comfort zones.

What say ?

Harmony between Multiple Management Theories

One of the promises and a great point that theories of
1. JIT
2. Critical Chain
3. Agile Practices
4. Earned Value Management
5. Systems Thinking
propose is to streamline operations and management across every key business functions. And the target of reducing waste is multifold:.

1. Keep near to zero inventories
2. Identify the bottleneck (Constraint) and work to eliminate the constraint. Never let Inertia be the constraint
3. Make Velocity the primary driver on projects
4. Plan closer to realities and meet forecast due dates and costs every time
5. Ensure to look at whole than to address it in parts (more appropriately think long term than to spoil it for short term gains)

What each of the theories explain is in harmony with other theories. It is the context and culture that defines the importance of a theory over other that determines the extent of practice within an organization and industry. Manufacturing and automotive industries is
where JIT had its origins. Book "Goal" where ToC parable was made known
to everyone is set in a plant. IT and software industries do not need warehouse inventories as they rely on human capital. Hence agile practices are more common. In RnD organizations, science and infrastructure industries that need heavy investments and need long term management for results and control on cost escalations, EVM is more appealing. 
In my experience at team, product, project and service management, I realized that bringing in the understanding from each of these theories and crafting your operations model is a great way to deliver exceptional customer satisfaction, team achievements and a sustainable long term sustenance of business, teams and clients than a short get-together for climbing up professional ladder.

State of Mind for Instruction Designer

I have the luxury to watch my senior Instruction Design consultant working meticulously in a project. He has given me the language to express the function of Instruction Design to managers and non-ID teams.

1. It is a state of mind. Agreed that every role and function, beyond training, skills and competencies requires you to have the state of mind to bring out the desired output. For Instruction Design the state of mind and orientation is lot different. Creating content is about penning out phrases and sentences as it occurs to mind and is understood in ones mind. While Instruction design is about writing for an audience mind. There is a great difference in this. Only reflection can allow one to sink in the real value of instruction vs sentences.

2. It is about Analysis, Period : Instruction Design and Instruction Writing are interchanged to suit convenience (at least it is a norm in my country). If you do not find a person to write, hire an ID to do that job. You are unable to hire for Writing position, elevate them as IDs.

However, a good Instruction Design practice and ID is not about writing (a flair and love to write is important and critical though), but keenness to analyze reams of pages of content and build up measurable objectives. First build and define Performance objectives. Performance Objectives evaluation is done 2 ways. The primary method is interviews and management vision on the job skills and competencies required. The secondary and most often used method is to glean them from available content. Based on Performance objectives, repeat the analysis to determine the learning objectives and the sequence. This is a pain and the most tough portion to absorb the content to measure them in objectives.

Go back and forth on content to now map the content to learning objectives. Invariably gaps in content will surface. It is here that ID dons the hat to bring in relevance to existing content and make them closer to objectives.

 Doing this analysis is often skipped and most times in projects, a content material is read and re-read to be re-purposed into smaller instruction units. A proper analysis phrase is where a true ID professional delivers on value.

A good analysis phase in my current project has realized productivity gains of 60% in storyboarding phase.

3. It is not about English alone, It is about the subject: I have often been told by bosses to groom and pitch in people with good command of English as IDs. Have went that path too, although reluctantly. Observing my colleague I realize that it is not English and the grammar theories to look for grooming a candidate in ID role.  It is only in the person whose state of mind can amend to ways for grasping the audience and subject is a valid candidate for ID grooming.

4. Instruction is visualization : Couldn't feel this or accept this, since it is verbose as opposed to common thinking of seeing graphics. Visualization is key to writing an instruction. Instruction delivery is key role in Instruction Design phase. And that is why writing instruction is not about writing sentences. It is about consistency of saying similar and same things the same way every time. Try this and you will know the state of mind required for this one is much different than content creators.

Visualizing the reading mode and style and adapting to write steadily is what a good course is all about. Graphics, animations, interactions and functionalities are all manifests of visualization and allows choosing the best instruction type for conveying learning intent behind sentences.

5. ID delivers metrics for learning and training: This can be laughed at or could be ignored. It is not in one course or just courses that a user can learn and become productive. Since schools and college degrees and learning do not get us to become professionals from day one.  It is repetitive working and learning from peers on job and mistakes we do that we develop most of time.

Which of the two statements appeal to you will determine your liking to the point.

1. A course is a result of a goal.
   
2. Courses are a means to enhance skills.

If you are going with #2, then it is time to look at #1 seriously. ID as a profession is to measure the output against business or personal goals. Measurements to state the degree of closeness to the competencies, skills, gaps and strategic intent of roles and responsibilities within a context is all what a course can emanate to a metric system.

The level of awareness, level of understanding, the compatibility of reacting to situations is what courses teach. And if analysis is done right, measuring from learning to performance can give you measurement oriented results.

In practice, having worked with a large number of Instruction Designers, these qualities are what an Instruction Designer brings in to the success of project teams. The state of mind of ID is a specialized skill. Misunderstanding it as a series of steps and templates to execute is not a good way to perform the function.

Chime in for more learnings...

SCRUMmers and Crack Teams

With news of Osama death and the news of how the crack team that executed it replayed for 2 consecutive days continously, couldn't help but liken it to a SCRUM team. SCRUMmers like crack teams:

1. Have and Share a Plan,
2. Assemble quickly with Tools,
3. Decide the Goals,
4. Get started and
5. Finish it in Short Time.
6. More importantly, Move Over.

While Osama as a non-living being generates lot of talking, wonder where the crack team is doing the next op.

SCRUMmers, be proud. Welcome aboard!!

How does Performance Stay in Agile

This has been my fear ever since adopting SCRUM and have mentioned it earlier. While going "gaga" about agile methodologies adoption and the magical benefits it has instilled in teams and deliveries, there is a fear if it could be sustained and adapted across projects. Part of it stems from my own fear of failure and the new frontiers that I was getting exposed to.

Am starting to see patterns emerge from SCRUM adoption on why it moves from a one time change wonder to a way of leading a disciplined and high performance professional lives.

Once you are in SCRUM, the simple techniques become simpler. The techniques that you practice because of SCRUM mandates become part of routine. Updating Impediment logs, Checking Kanban stickers, daily SCRUM calls, Sprint planning and retrospective meeting all become a habit that promotes

1. Individuals and Interactions
2. Client collaboration
3. Responding to changes and helping along the way
4. Focus on shippable product deliveries.

So my aha moment came from knowing that it is the methodology that drives the success, but realizing the goals of agile manifesto is the formula for ever lasting success.

Sounded so obvious. But it took me practical implementations and conscious analysis to understand the manifesto better.

I used SCRUM and achieved Peak Performance

Yea, it sounds a bragging statement. Yet it is true. It is factual. It is real. It is current and NOW. It is a first person experience account.  The facts and numbers speak for themselves.

I went the agile way for its novelty. I had to bring in some freshness to overcome then problems and also drive confidence in clients and teams alike. I used agile as just another "all encompassing" magic bullet. Knew it is the best I could to buy time. And it will allow me to set houses and expectations in order.

Not that I wasn't exposed to Agile and SCRUM earlier. My technical team under its SCRUM master was the pioneer to introduce and lighten me to the potential. It is a brand new team, fresh from college and a new technology that isn't mainstream too. Yet in 4 months, the learning and progress is amazing. Together holding the team and product focus along with progressing to a shippable state is a great achievement.

Yet, the situation in the product team isn't comparable with pressures and stress of a real client project. Soaring expectations, delays in project start, cost escalations, quality issues, all were hitting the epicenter of a downside. Neither do I have a hero nor a great leeway with budgets to get in right skills from market or rely on an entire management pool to set things right. It was bound to be a team commitment.

So along with SCRUM method for agile, I relied on Kanban and EVM (Earned Value Management) to help me stabilize the ship. And my colleague used to say that JIT promise of zero inventory and Agile promise of quicker yet better deliveries are true theories and lofty ideals. Measuring and you can get close but practically you fall short. Alas! it is not to be true.  Agile truly is a scalable process that is adaptable to any business surrounding. In e-Learning content projects, project planning is a futile exercise. Tight dependencies between skills, waiting periods for deliverables to start work, multiple review cycles towards final product and one global change in middle of project is enough derailment for the entire exercise.  Every time you put a schedule, you shift baselines practically every day.

With SCRUM, EVM,Kanban, and Support and Maturity of your team, I realized that each successive deliverable is transformative and each time you see a new shippable version, it is not just improvement, it is closer to  WoW!!.

Comparing my experience with Agile Manifesto, I believe the  following points are the critical factors in shaping a good success project. In e-Learning projects, achieving this is a true popping, hair-raising experience.

1. People and Creativity over Processes and Hierarchies.
2. Common sense and drive to end deliveries over Documentation and Intermediate review cycles.
3. Transformation over Improvements. 
4. Help others and Empowerment over Individual tasks and Shifting Dependencies.
5. Interactions over Protocols.
6. Bond of Like Minds and Shared Goals over Mandates to silence Disparate goals
7. Levels the hierarchies with only one parameter: Performance!!

SCRUM has now given me another headache. The ache of peaking performance and soaring quality levels and negligible errors, that I now fear if it is a sustainable exercise. Client expectations is not just met, but the baseline is now perched higher and hoping it doesn't lead to more work.

Best of all, you do not have to take pains to identify the non-performers. They almost give up and you can find them lagging in the queue. It is  automatic and every peak performer gets along to take the project to greater heights.

Agile Culture: Maslow and Peak performance for real success

I realized that goodness is when people expect gratification to flow in. This is precisely the fallacy of an agile team. Hence managing in an agile set up requires a cultural shift towards great performances and the distinction from good performance.


It is hard and all of us wouldn't agree and debate endlessly over good vs great. Since till the time discussion veers around greatness, there can be an objective comparison. So much written as Job Description needs to be carried out, so many results showed up, comparison with peers it is better, etc is how good gets measured. But while talking about greatness the discussions get subjective in nature and challenges the self over-looking and ignoring peers in that social environment. This is very troublesome. How can a good performer be criticized for not living up to their potential while we leave away non-performers and worst yet, the treatment ain't perceived to be that harsh on non-performers ?

Challenging better and top players in a team, makes no sense that why they are being singled out inspite of performance. When I was confronted with a troubled colleague in this situation, I couldn't help request my friend, Maslow to help me out. Maslow has anchored me in lot of psychological understanding situations in my career to help me understand the motives and spots to allow me to work with them in win-win scenarios.

Reflecting on Maslow, to me for an agile team culture, requires an empowered and truly self-esteemed team to make it work. Since agile is about thinking, adapting and continously improving the work areas. This cannot be achieved with teams where members have a sense of fear of their jobs, the consequences of making a mistake or speaking out in a forum with divergent views.  Agile team require every element of above to get tasks done well and quickly.

1. Finishing a job quickly and your pay is linked to effort hours isnt going to get you in an agile team.
2. If a boss is non-tolerant to ideas or ignores need for discussion, or cannot accept the complexity of the tasks is going to affect the safety needs of the individual and the agile team isn't in safe hands.
3. Every person needs to present their ideas. This is highly appealing part in SCRUM retrospectives and stand up meetings. If you are cut short and cannot bring the issues or tasks completion to surface and request help, social needs of the individual aren't addressed and in name of agile, there is a failure waiting to flare.

Building on physiological, safety needs and removing the doubts in these layers is critical for a truly agile and great performance. Sense of job worthiness, and safety of job along with recognitions allow members to concentrate on thinking to get job done than rely on command structures to finish tasks and get away quickly.


In self-esteem and self-acutalized world, individuals care for their work, their efficiency and are non-tolerant towards noises and defensive postures that gives the required strength to agile teams to make the world better.


How you get a team of self-esteemed and self-actualized individuals together and make them work towards a common cause is where my current priorities and reflections are. What is your agile team composition and how does it work in your team ?

Irksome Kanban : Why Agile Teams Perform and Deliver

Kanban can be a pain for sub-optimal teams, because of the meticulous and instant way of letting everyone know of availability to take on a job and weighing in of task queue.

Project plans, Status reports, Driving deliveries by Numbers are all a purview of management teams. However, when they are handed down to the floor, they are instructions and tasks with deadlines. This leaves a lot of undesirable communication gaps, narrow focus to work, dependencies are uncared for, and it becomes a single person responsibility: The Project Manager.

A thriving team needs to be well orchestrated by the Project Manager. The members need to sync with each other  to create a symphony. Disenchantment, Attrition, clueless wanderings, and side goals all make a manager job heavy on any given day.

Kanban is a simple system to keep track of work in hand vs work in pipeline. This is easier to tackle bottlenecks and focus on the critical path in the chain of delivery. Prioritization is transparent and tradeoffs are well received. It leaves less ambiguity with teams working on improving products, projects and hence enables customer satisfaction.

Since the Kanban system exposes hidden vulnerabilities that otherwise are often hid behind a facade to showcase the best in management reports, it is irksome tool to review every time. Exposing details will make the teams and stakeholders to face each other realities and address problems on a daily basis. SCRUM documents these issues that are uncovered in Kanban in its Impediment Log.

Impediment Log is an Actionable Report. Kanban is a velocity indicator. Any hidden abnormalities surfacing on an immediate and daily basis triggers actions and reactions throughout teams that gives strength to ask for support and help from the project ecosystem. Be it asking for more time from client, informing the client of added tasks and measuring change impact, enabling managers to take sound resourcing decisions, Optimizing and prioritizing work load than over-loading teams to perform, diligent watch on quality as they move through the queue and control build up of just enough inventory to manage and care for project completion with all-round satisfaction, Kanban board is a great visualization tool.

And without this discomfort and getting irked with uncovering and solving impediments while moving through the chart, it is always difficult to motivate, drive energy and make deliveries consistently and in an optimum quality thread.

How has Kanban boards helped you ? Would like to hear your comments.

A great Kanban App - Simple Kanban

via simple-kanban.com

I love this app. Simple, Effective, True to spirit of Kanban (no frills or show off designs) and makes project management communication intuitive and transparent to all stakeholders. The focus is on the movement of tasks in various project stages to completion.
Traditional Project Management focuses on 2 areas.
1. Tasks complete and calculate % project complete based on this roll up score.
2. Control flow of tasks to manage resources and dependencies.
Kanban addresses these 2 areas differently and in my opinion more correctly.
1. Task complete is not equal to % Project complete. It is possible that we burn money on completing tasks, but have failed to realize output. If you look at the board, the % Project complete is a function of your
(Release Ready Queue count - Total queue list count)/total queue.
**Total Queue list should exclude release ready queue count. Ignore negative sign while looking at %.

2. It is important to optimize resources time and hence instead of managing task dependencies through dates, manage on keeping the queue active and moving. This way, resources can pick up tasks in queue after they finish the first job. This frees up tight dependency waiting lines thereby boosting productivity for both teams (in dependency chain).
Release control on tasks completion and focus on managing queue. This means that instead of saying "Finish task by a certain date" , you will focus to say "Move deliveries to final queue by a certain date." Working backwards, you will start to focus on moving current tasks to next queue before the next queue dries out and the current task queue overflows with backlog.
It is a perfect pitch to have tasks waiting for resources than resources waiting for tasks. Resources working on tasks earn revenues. Resources not having tasks are cost leaks.

Do not control resources working time (there are unproductive hours in a day for every one), rather direct energies to control time spent on tasks. This means that instead of checking if a resource is punching job card for 9/10 hours, check and control if Task A consumes more time than estimated and how it affects the queue build up Velocity.
Kanban charts give away a lot of answers while we follow them than chase problems for solutions.

Positive Endorsement with SCRUM: Simpler Schedules, Recurring Habits

For a long time, as a manager, when I put together a schedule, releases happened according to a predefined dates or so it seemed. When i looked back to realize the patterns, it was a surprise.

The patterns that emerged from my schedules was that release dates pretty much happened on a certain day of the week. Let us say, Wednesdays is where 70% of my releases were done. Remaining 20% releases always alternate between 2 days. (Say Fridays and Thursdays). But this was arrived after a laborious exercise and arrived after careful considerations of work, tasks and dependencies.

And one rule, that  I usually follow is to not give too much lag between deliveries. This is another important consideration that sustains interest and reduces risk of changes and wild ideas that change course. So the timing between 2 deliverable is consistent and coupled with release dates falling on same day, it is an easy one row schedule that can be set up as a recurring meeting request.

A simpler schedule that can sit on your calendar allows you to develop recurring habit. And this recurring habit ensures you dedicate the time required and it does not accede to other priorities. Further, allowing to set an expectancy date, gives expectations a positive endorsement and looking forward for further conversations. Just make sure that the waiting period is worth it with a new release, new fixes and make it fresh with a good presentation.

SCRUM is a great tool to set up invites. With fixed duration sprints, you always develop the recurring habit to see something new, fresh and ready to ship version that sustains the interest and gives expectations a positive endorsement.

Happy New Year

As we start our first day of week in new year, I wish and pray Prosperity for your

1. Ideas, Wishes and Dreams
   
2. Family, Friends and Acquaintances
   
3. Happiness, Health and Wins
   
4. Business, Wealth and Society
5. Calm, Contentment and Care
6. Goals, Mission and Truth
7. Knowledge, Learning and Actions
   

Have a all-round, evergreen, everlasting, successful NEW YEAR 2011.