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.

SCRUM based estimation: My learning from an e-Learning RFP

Recently I had the experience to estimate an e-Learning course development project based on SCRUM.

Usually I do a bottom-up feature and asset level estimation and the results are more accurate for planning and nailing scope in proposals. This is pain staking and in absence of lot of inputs, I need to rely on best judgment and use collective intelligence of team to identify and scope them. But it has always been worth the efforts. I then tally them into a Gantt based project plan to identify dependencies and factor in schedule and efforts for lead and lag times between teams and tasks. This adds up the cushion to handle project delays and exigencies profitably. Surely, Gantt based estimations shoots up the estimates because of the time the resource gets blocked in non-working times. Then there is a middle ground decided by bosses based on risk factors to ensure there is a winnable proposal.

For first time, I did a SCRUM based resource loading estimation in a recent RFP. I was sure that it is going to hit the roof. Because the initial understanding was that it is another way of resource forecast estimation in a new fad word (just a variation of Gantt based model that I am used to).  How wrong could I be ?

The beauty of SCRUM is that the estimation can be done both ways.

1. Estimation through user stories (essentially a bottom-up estimate technique) OR
2. Estimation through SCRUM team composition (Resource based estimation)

And when I used SCRUM for first time, both models, surprisingly gave close match results. Upon analysis, I realized that SCRUM premise and success is in the way idle time gets minimized. This, otherwise gets factored in resource allocation and estimation. Plotting the tasks and resources in Gantt mostly shows that utilization of resources optimally is a big challenge and is a trade off with other parameters either schedule or add in more people to finish few tasks so that dependent resources are ramped up on time.

 The foundation in SCRUM teams is that in a Sprint there is no idle time. There are schedule buffers, to account for waiting times between dependent tasks, just in case of a need. With Kanban use, there is always a queue of tasks/features and there is progress of the queue across columns. Each member is expected to move the queue from head to finish by owning their work. This is akin to a conveyor belt of task supply that gets picked by resources in a continuous stream. While tasks may wait for resources, it isn't always the other way around. This is profound. Because task waiting to be picked up doesn't expand the efforts or consume additional resources.

This is the change that SCRUM teams are advantageous about. There isn't a fixed flow. If there is a dependent task that is delayed or not available, instead of waiting for the assigned one, pick up one from the belt that is ready for your work. Thus idle times are minimized. Hence resource based SCRUM team estimation planning nearly and accurately maps to the bottom up estimation.

Further, SCRUM promotes high level of camaraderie between members to assist each other in finishing tasks that are taking longer by a single person. This too makes it possible that there is no waiting or lag time for resources to wait for work.

Bottom up estimation is the default model of SCRUM working. You estimate time and efforts per user story which then rolls up to a final shippable product estimation. So if a task or a feature is in a conveyor belt and not picked up, it just means that productivity has improved in teams. This then gets factored in successive Sprints thereby reducing the waiting times for tasks to be moved in Kanban card system.

Further, clients who are savvy about SCRUM or if you had done a workshop for the clients on SCRUM, you are bound to get good information upfront for estimation. Instead of assumptions, you can readily use user stories to base your budgeting and estimation models.

Sounds great, isn't it. Come onto SCRUM bandwagon and you will realize the marvels of a simple technique that answers age-old problems in estimation of e-Learning projects.

SCRUM and SCORM: A compelling case for adoption in e-Learning projects

Be it
1. An LMS customization and implementation
2. A new Product Creation
3. An e-Learning course development

SCRUM snugs well in all e-Learning implementations.This post is to iterate my thoughts on #3 above.

Most e-Learning course development contain inherent ability to package and publish the output as a SCORM package. For this post, I wish to request my readers to understand SCORM as a course asset model that allows to slice and dice courses into independent small size units called as "SCOs". SCOs have a great importance in reusability, durability and configuration across multiple learner groups and can be packaged across multiple learning modules. This is the benefit of SCORM apart from making it available across multiple LMS that support the specifications by allowing interactions between the courses and LMS.  SCORM makes for a great way for course designers to think in terms of packaging and easy access.

Where SCORM does not specify a way of execution, SCRUM fills the gap to showcase that execution of SCOs in Sprints makes for a better experience for clients and project teams alike.

e-Learning course development mostly follow a flavored variation of ADDIE model (which is likened to waterfall software development). My experience, thus far, has been that Instruction and Visual Designers thinking is always top-down ("AD" phase in ADDIE). Think of course at large, break it down as MLT (Module-Lesson-Topic) structure and then define SCO level. Then start work at SCO level based on templates, guidelines defined at high level. This is not wrong at all. This has been working well, so long until SCRUM changes the paradigm.

Top-Down design thinking has its merits. You define consistent writing styles, Instructional approaches for content treatment, color palettes, Interface elements, determine the navigation flows and drill down from overall business objectives to atomic level terminal objectives. This established upfront leaves developers and writers to publish courses with ease.

In this approach, when you request for a change to better, it becomes a limiting factor. What is good to digress becomes a one-off case or a work around. What is the ideal treatment style suited to a particular SCO, becomes a change request if not factored in the earlier design phase. What is required as a logical extension but not factored in earlier analysis phase becomes phase 2 or version 2 of the project. For larger implementations, beyond 3-4 months, a stagnant document driving the development suffers from dull teams executing with hand and not with brains. In many cases, the relevance becomes obsolete.

Every designer knows that although you arrive at design using a top-down approach (if done so), it is always an aggregation from bottom-up that makes real sense. A collection of terminal objectives satisfy a learning objective, a collection of learning objectives satisfy a business objective. We call them "Roll Up" objectives. From course standpoint too it is an aggregation model that makes meaning for ROI to training managers. Consumption and mandatory access of learning units aggregates to determine the project priorities and these in turn define the budgets for training. (However, still budgeting is a yearly top-down affair).

The definition of SCOs is left to course designers way of sizing the content and many a times based on the limitations of LMS/business requirements within confines of SCORM.  So designers either get to treat the entire course as SCO or a Module or really treat small topical units as SCO. In practice, there is no right or wrong approach in determining what is considered to be a SCO. 

Consider the case of users and learners for whom the whole industry strives for best experience. Users  knowledge is an aggregation of multiple learning units and past experience and learning that lets them perform better. It never happens to have a direct one to one correlation between learning a course and improvement in performance. It is an aggregation of learning from multiple sources that aids and betters performance. It is multiple insights from learning and their application that a job gets executed well. 

SCRUM comes around as a more meaningful approach towards design thinking and sizing of SCOs. The primary reason is that SCRUM at its fundamental level delivers value by aggregation. A collection of user stories determines a SPRINT, Every SPRINT delivers a shippable product. A collection of SPRINTS allow for successive iterations towards the desired goals.  Every Feature is prioritized and iterated in multiple SPRINTS thereby delivering maximum value while keeping overall vision in mind.

For commissioning any project, you need to have an intent (Vision) at highest level. But beyond that, every big thought is written down  and broken down to finer details as shared (user) stories. (in e-Learning terms SCOed). This allows for better design thinking at shared (user) story/SCO level and applying the patterns common across SCOs/user stories that unifies than homogenize the entire course.

Thus when SCORM meets SCRUM you get to see an exceptional output which retains the localized and unique customizations required at SCO level, while larger part of design is driven by commonalities across SCO units.  So instead of homogenizing SCOs as is done in top-down version, thereby bringing in monotony in treatment, you get to unify by applying designs that work at SCO levels, making SCOs truly stand alone as an independent package.

Does this mean each shared (user) story is a SCO. Possibly yes. But the flexibility is at designers desk. However, common sense dictates that you will not make a larger SCO than user stories.

 I am realizing the merits of this approach in my current assignment. Looking at design parameters at SCO level and rolling it up, gives far greater freedom to designers, writers, producers to improvise on the final output quality. SCO is the access point where users spend most of their time. This is where they will make opinions on your work.  This is the moment of truth for users to get maximum worth for their time. This is what business managers will eventually learn that their benefits are derived. Hence focusing on them that SCRUM greatly emphasizes on, is a better approach.

Welcome SCRUM to your e-Learning projects development and am sure of far greater productivity, happy development teams, clients and users.

Let me know your SCRUM and SCORM story.