Learning Practice

Loyalty is

2012-02-05T01:14:00.001-08:00

A structure: A common ground where self interests are aligned with group interests.

Self Interest example: I need to have a work life balance.

Group Interest example: Helping my mate who has to give me the working output and sharing status helps groups become loyal to each other.

A System:

A series of dependencies which flow both sides (never a one side giver or receiver) and inter-operational hand-offs that helps people not distinguish “me vs they” but accept “me” while thinking about “us and we”

Based on cycle of relationships: It is not just work. It is not just about spending time in office or home or with a constant group for a period of time. It is about sticking yourself up predictably every time all the time in the same zeal, vigor and support for the same group. Relationships transcend time and place and beyond this place is where loyalties are born. Any time and in any place cherishing a presence and feeling a relationship is what makes a group feel so special.

Built on core values and shared principles: What you are at heart and/or desire to be is the core value. Wanting to be fun/sport/debate loving, truth seeking, always seeking/helping out or experimenting or being constantly challenged are the core that becomes the reason to thrive and live the together moments happily.

Feeling these moments are enabled with shared principles. How each of the partners behave, live and shape the core and how it gets adapted to the personalities in relationships allow degrees of loyalties to be developed across individuals.

This possibly will be my last post in my current profile. Am thankful for the mates for the wonderful loyalty and camaraderie shared with each other and wish they last forever.

#Sheena Iyengar: How to make choosing easier | My Synthesis from her video

2012-01-20T05:10:00.001-08:00

This is Sheena Iyengar video. A must watch for designers and solution providers. Love her speech, modulation and simplicity. It will do a lot good to remember her messages and look at how we can apply it in our relationships while providing solutions to clients.

Here is how I could relate to my own approach towards e-Learning solutions and SCRUM teams.

1. Limit choices to client for accepting and appreciating your solutions better: Do not show too may design options of screens. Create maximum of 2 and adapt screens to not more than 4-5 templates per course.

2. Provide concrete consequences of each decision or change or requirement to drive projects towards closure. Make it more visual and real than writing documents and pushing more and more descriptive text.
Make weekly charts on budget and schedule burn and forecast. Use it to iterate on impact of every request on schedule by making what-if scenarios to drive the acceptance on a holistic level. Create a minimal working proof of concept to iterate on the working.

3. To me this is important : Categorization. You can handle more categories than choices as categories help you to tell them apart. This is critical to understand why metadata is important in web world. Why we should assign semantics and leave a trail of our own synthesis to make web world more intelligent. So categorize your options and limit choices within each category. Create a short team and project vocabulary that is distinct and has unambiguous meaning. Apply folksnomy and taxonomy in communications so that it is easy to index and refer it from archives

4. Condition for complexity. Gradually introduce new features and move from simple to complex. Introduce one/few features at a time in solutioning world. A reason may be why niche tools that accomplish one task well than multi-approach tools could be why we stick to the app and become loyal users for a long time.

When you introduce a new interactivity, animation, new process, a revision to an existing priority, allow and give sufficient time for its acceptance. Do not rush on releases or changes in a train mode. Rather bursts of releases at predictive intervals enables to understand changes better.

A great use of time watching this video. Highly recommend it.

http://www.ted.com/talks/sheena_iyengar_choosing_what_to_choose.html

e-Learning towards direct empowerment - My wish list for 2012!!

2012-01-13T03:57:00.001-08:00

e-Learning as an industry has succeeded to hold on to its promise of

1. just in time,

2. just in need and

3. just on request access to information and training all these years.

In the last few years I have been happy to feel and see the following transitions in e-Learning projects.

1. The project success rates have gone up and initial cynicism of adoption has gone down.

2. IT departments have now entered the domain to sponsor e-Learning projects (while it was earlier primarily sponsored by business teams). Hence the adoption of e-Learning solutions in main stream IT initiatives will augur good news for the industry work force.

3. e-Learning as a medium while still being initiated as a cost control mechanism in training (at least first time adopters start small on this basis) has blended itself well with ILT initiatives and has started becoming main stream in delivering on results and improvements.

4. The awards, reviews and recommendations have all grown up and cloud based solutions have made their mark and e-Learning as an industry is a leading adopter of these technologies.

What I wish to see in this year and my focus areas will be on the following trends.

1. Proliferate Meaning to Mobiles: Apps on mobile, Social Media on mobile and Transactional communications have held sway on mobile usage. In this scenario, making learning happen on mobile and vying the same screen space with multiple tasks on same device is a tough challenge. I am not talking of m-learning or making courses available of mobile.

I will be looking forward for meaningful solutions that are making sense for professionals that enable doing their job better.

2. Move over Learning Management Systems to Dynamic Learning Systems: LMS has, by far been thought of as a single window application to launch e-Learning courses and show reports on progress and performance.

Sadly, the dynamic interactions and re-living reading history has not got adequate attention in the e-Learning journey. Remember, when we were learning from a book, we take notes, book mark, highlight, talk to peers, read journals, magazine, reference books rehearse some quotes, sentences in our quest to understand the subject well. We try to rephrase them and analyze these multiple records to create our own internalization of content. While these are considered as functionality and tools are built enabling them as functionalities, their way of usage within courses often leads us to get distracted in juggling between multiple apps.

When we look at our own bookshelf, we tend to look at history, open a book and try to remember our learnings, scan through random pages, check the marks, notes, scribbles and get new perspective within revised context and experiences. This dynamism in e-Learning course-ware currently is boxed within courses themselves as few functionalities in header and footer or navigation panel instead of a naturalisitc progression towards deeper knowledge and wisdom.

My take is to see a different paradigm of dynamic learning being adopted by industry and next evolution for great learning involvement come from more dynamic learning systems and platform. We would need such action tools while learning or recording own contexts from where the learners are getting the content.

3. Power to Users for Learning Exchanges: I am a big fan and had in earlier blog posts shared that learning exchanges and facilitation, needs to be at forefront of any learning medium. I wish that social media platforms are harnessed and creates a system of good, steady learning exchanges that makes e-mediums a powerful learning accelerator and transformation tool. Also more power and time is accorded to live human interactions and not just promote tools and applications to rule our learning environment.

Happy Learning for life time!!

SCRUM way for productive meetings

2012-01-04T04:48:00.001-08:00

Next time, you want a productive meeting don't share the agenda. Instead share a questionnaire that each one needs to represent themselves in the forum.

SCRUM in its definition emphasizes 2 meeting models in each sprint - stand up and retrospective. Both have different purposes yet same goal - make meetings productive and useful. The tools I use are surprisingly simple and hence sharing it here.

The tools are:

1. Questionnaire:

For stand up, I use a mind map to record standup meetings. The key questions people need to prepare each day for the meeting are:

a. Can I finish my next day tasks as planned ?

b. What risks do I foresee and what is the support required ?

c.My next days tasks are: ___ , ____ and ____.

d. My previous day tasks status is ___

e. I want to share that ____ (share problems solutions ideas, etc)

For Retrospective, the template I use has following simple questions.

1. list at least 3 positive points you experienced in the project?
2. list at least 3 negative points you experienced in the project?
3. list at least 3 important take away learning’s from the project?

4. Rate your experience while working on the sprint ?
5. Rate the competitiveness of team working with you ?
6. Which team member would you like to give a credit ? (this is the motivation question for team to feature themselves in each sprint).

Each member fills it and sends it before the meeting. Without which the moderator doesn't start the meeting. This is the ensure that members speak well thought out points and not adapt their pitches at run time.

Questionnaires allows you to think through the audience required and the participation and expectation from each teams so that meetings are steered to be productive.

2. Rules of game:
In both stand ups and retrospective the rules of game is simple.

a. Each member gets their turn to speak.

b. Any disagreements can only be registered and only when floor is open to discussions the differing points of view can be shared.

c. No insinuations or personal attacks allowed.
d. Moderator decision is final.

3. Moderator

The meeting organizer becomes more of a floor coordinator and time manager. According to individual styles, you can choose to conduct the meeting. The only key is to enforce a timer based system so that preparation becomes key with every member and equal opportunities are presented.

Not necessary that you use the tools in sprints or SCRUM context meetings only. As I have seen, am sure, you could see a transformation in participation of all members and no one would ever complain that meetings are boring and long winding.

Use in any business context and I shall be happy to showcase your results on this blog.

Self Quote

2012-01-02T12:06:00.001-08:00

"Being indispensable locks you into continuation. Dispensing yourself, then is the key for disruptive growth."

Keep that Smile Going On...

2011-12-31T05:54:00.001-08:00

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

2011-12-29T11:39:00.006-08:00

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

2011-12-26T21:51:00.001-08:00

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 ?

2011-12-07T19:15:00.001-08:00

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

2011-12-05T04:30:00.001-08:00

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

2011-11-20T09:09:00.001-08:00

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

2011-11-06T17:25:00.001-08:00

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

2011-10-05T21:11:00.001-07:00

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

2011-09-29T22:25:00.001-07:00

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.

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.
The Capabilities to execute the available capacity gets the attention thereby enabling larger throughput and increasing efficiencies.
Managing Capabilities establishes mature HR processes and seasoned managers who are task and vision oriented than handling capacities which is an administrative overhead.
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.
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.
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

2011-09-27T20:30:00.001-07:00

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

2011-09-27T20:16:00.001-07:00

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

Connect and construct them to the source(s).
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).
Investigate how these parts enabled/disabled others functions in the system or discover the objectives for which the individuals and independent resources were integrated.
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

2011-09-11T13:19:00.001-07:00

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

Happy Teachers Day

2011-09-05T07:10:00.001-07:00

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

2011-08-08T20:30:00.001-07:00

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

2011-07-27T06:27:00.001-07:00

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

2011-07-26T07:33:00.001-07:00

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

2011-07-25T07:30:00.001-07:00

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

2011-06-24T11:26:00.001-07:00

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

2011-06-09T05:28:00.001-07:00

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

2011-05-18T02:08:00.003-07:00

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.