The middle management is a transformational change agent exhibiting industry expertise, business acumen, negotiation skills, empowerment skills, and strategic leadership, according to my post-doctoral TONES research. I present my ongoing observations to demonstrate my commitment to continuous learning. For more games, thought leadership, book, and KOL talks, please visit my site.
Search This Blog
Wednesday, December 31, 2014
Acceptance Testing: Demystified from a business perspective
Sunday, November 30, 2014
Cost of Quality: The increasing value of acceptance testing besides automated testing
- Eliminating the number of testers increases the level of effort on the remaining testers to check every test case as thoroughly as possible introducing errors. The testers that have the accountability to ensure that they don’t release features without signing off are under pressure compromising the quality.
- Keeping more testing resources also does n0t guarantee zero quality always when the testers don’t keep up with the current trends. The number of communication lines increase with the QA manager, test lead, offshore test coordinators, and testers. This functional hierarchy removes the testers from the developers defeating the self-organized team requirements. Consequently, the requirements dilute and morph leading to management problems as the customer complaints increase, time to market slips, and product reviews decline.
- The client facing roles mentioned earlier may actually question why they should do this testing that the testing department is accountable for? It is a valid question but when buying a car why do you want a test run? Why do we do our own walk-through inspection of the home instead of leaving the work completely to the home inspector? We do these because we are equally responsible for the outcome. As these roles face the client who can claim escaped defects or the features for enhancement, how could these responsibilities downplayed?
- Let us face another argument of being busy to do this acceptance testing! When automation is introduced, the developers and testers have to write additional lines of code and test scripts to ensure that the automation works according to the 3A principle (Arrange what needs to be tested, Act by developing code to test, and Assert by evaluating the outcome against the expected). This needs more time commitment and learning additional tools where the developers and testers need to immerse themselves to evolve to the expectations of today’s workforce. So, if one group that is busy can increase their competencies, why should not these client facing roles elevate their skill-competency gap instead of claiming the busy life?
- Another important angle to consider is new functional non-customer value add requirement but a business value add requirement, such as the heartbeat monitors, exception log checks, and time taken to test checks as part of the automation efforts. None of these requirements are part of the actual product feature a customer sees but are additional scope of work that the business mandates on the execution wings to design, develop, and test. When these are baked into the level of effort or timeline and when customer asks to reduce the time to market, the client facing roles cripple the quality by not standing up for best practices.
Friday, October 31, 2014
Adapting Scrumban to Personal Productivity
Scrum
|
Kanban
|
1.
Scrum focuses on timeboxed iterations with
self-organized cross-functional teams.
2.
Team decides on what can be accomplished in a
2-week sprint and emphasizes continuous improvement by retrospectives
3.
Customer representative is expected to be
sometimes on-site and be multi-functional with skills in product, project, account,
technical, business analysis, etc.
4.
Measure of progress is working software
delivery
|
1.
Team visualizes the workflow in queue
2.
Anyone can pull (i.e., take) any task that is
in the queue
3.
Tasks are generally not dependent
4.
Balances work in progress
5.
Reduces waste between tasks
|
Tuesday, September 30, 2014
Role Mergers: Is middle management – product, account, program, and project - learning from failure?
Saturday, August 30, 2014
Differences between Kanban and Scrum
Concept
|
Kanban
|
Scrum
|
Management focus
|
Maximize resource usage avoiding delay and enhancing accountability
to support flow.
|
Consistent delivery in the cadence of execution, as the features in
the product backlog is delivered.
|
Operating rhythm
|
No time-boxed iterative development exists.
|
Time-boxed iterative development – usually two to four weeks.
|
Granularity of work
|
Focus is at the task level for which the scope of work is generally
known.
|
Focus is at the user story level for which the scope may not always
be known, requiring it to be estimated before tasks can be identified and
taken up by the team.
|
Agile Estimation & Planning
|
Estimation is generally not done. There is little to no ambiguity on
the task that any member of that team should be able to take on the next
available task and execute it.
|
User stories are estimated. Then, they are prioritized and risk
adjusted so that these are included in the release and iteration planning.
|
Value Delivery
|
Every task completion may not necessarily add minimally marketable value
to the customer. Task identification and dependency require careful
coordination.
|
The cadence of release and iteration planning focuses on adding
minimally marketable feature through the scrum cycle. The self-organized team
determines the task identification and dependency.
|
Progress Tracking
|
Flow of items throughout the lifecycle limiting delay. This is why
the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat
Yourself (DRY)” focuses on maximizing work not done
|
Focus is on tracking the velocity measuring the user stories done and
delivered to customer in an iteration
|
Utility value
|
Better for managing workload and resource management.
E.g.: How many projects of
different combinations can be taken up by a project?
|
Better for managing products, programs, and projects.
|
Thoughts to consider in software development
|
Use of Kanban for software development may impede flow if all the
units don’t consume the work produced at the same speed. Therefore additional
processes must be in place to support Kanban.
E.g.: QA not having capacity to
test code developed by engineering team. If QA’s capacity comes from the fact
that more defects are found in the build, then, more granularity in tasks to
ensure proper code review, unit testing, and documentation are processes that
the organizations must have in place.
|
Implementing Scrum doesn’t mean ability to write user stories and
avoiding documentation completely! This requires a management shift to ensure
critical thinking on the product, program, and projects. If iterative
delivery is not understood by the management and client, then, Scrum is not
an option to consider.
|
Monday, July 28, 2014
RACI: Errors and Implications in building the right one
Number
|
Challenge
|
Possible Problems
|
1
|
Too many R’s
|
This is the person that does the work! If there are too many persons
involved, then, the task is adequately defined leaving ambiguity in the task.
As a result, many people are required to perform.
Now, agile team may think the work effort is shared in a
self-organized team addressing central dependency of failure. This is quite
understandable, but then, there should be a fewer R’s. Per design, an agile
team should not be more than 7 in total including the scrum master and
product owner. So, if you see 3+ R’s
for a task, then, trouble is brewing!
|
2
|
Too many A’s
|
This is the person that is answerable to the management and resolving
impediments for the team when there is confusion! Too many A’s is an
indication of chaotic control. It is like everybody wants to be engineering
the solution but nobody is leading.
This could also be an indication of lack of knowledge in the groups
expected to be held accountable that holds the “R’s” accountable. Agile
addresses this concisely by having the product owner ultimately accountable
for prioritizing the user stories, decision making in the iteration backlogs,
and in grooming the backlog.
|
3
|
No R’s
|
This is an opposite extreme of an earlier problem and is equally
severe. There is no one to do the work! One may associate this with the “anybody
could have done the job but nobody did the job” because no one was held to
it.
This is a severe issue with the project management particularly. It
is possible to have this issue when a task can’t be associated with anyone
because the organization has not provided a structure to it. Then, this is
something that the project manager has to identify in the risk register and
follow through to get a closure.
|
4
|
No A’s
|
This is an opposite extreme of an earlier problem with much severe
risk exposure. There is no accountability for any work done leaving to
anything being acceptable leaving the customers feel the pain.
This issue presents itself in the internal team members having multitude
of meetings to figure our solutions leading to lack of productivity. When this
happens, there is a “Skill/task” alignment mismatch potentially.
In my humble opinion, this should not be associated people’s morale
due to trust erosion or due to organizational challenges. If any such thing
existed, then, the organization must step up to ensure that the
accountability is properly addressed.
No customer (internal or external) should be waiting on decisions or
success/failure requirements of a task as this is fundamentally against the
lean principle.
|
5
|
Empty spaces
|
If this observation exists, then, the RACI is incomplete. If this
really happens to be the case, then, the project manager or the person listed
as “responsible” and definitely the person listed as held “accountable”
should be raising their voice. If a comparable entry in the risk register is
absent so that this can be resolved, this is like an accident waiting to happen.
|
6
|
Mixed letters
|
Occasionally, it is possible to have an accountable function along
with responsible function. For instance, an internally facing project manager
also accountable to talk with the client. However, such occurrences should be
very minimal.
It is however not acceptable to see such occurrences in some areas
for tasks like “development and QA” or “QA and deployment” because this would
defeat the purpose of role-assignment matrix (RAM). If this exists because of
resource constraints, there should be adequate process control. Combined with
resource constraints and process gaps, this is a potential for “Quality
failure by design” and is also, I believe, a means to “Escaped defects.”
I also think that by definition a “R” and “A” are both “C” and “I” to
a large extent. But, listing “CA” or “IR” is an issue because then it raises
the question of whether the person is first consulting and then accountable?
RACI should avoid such ambiguities and should be a birthplace with mixed
responsibilities.
|
7
|
Lots of C’s
|
If too many C’s exist, then, I believe 3 potential problems may
exist.
The first one is that there is
a skill/task alignment with people listed as responsible/accountable leading
to decision by committee. No ownership exists and people are simply trying to
cover their trails.
The second one is that the culture or project itself may
be so risky that a number of stakeholders may want to weigh in and potentially
slowing down decision making and unnecessary escalations (needless to
reinforce here the number of communication channels that exponentially
increase here).
The third one is that the underlying processes and tools are
neither understood or clear requiring more conscious checking of “Am I doing
it right?”
It is critical for an organization to review the RACI in such cases
and address these concerns with an iron hand.
|
8
|
Lots of I’s
|
This issue may not be as severe as Lots of C’s but may be attenuated
in some departments. However, it must be acknowledged that “being informed”
is to be addressed in the communication plan of a project. At times, the
person listed as “I” may have to promote to “C” so that no project gets
derailed at times of scope creep, technical debt management, quality issues,
customer concerns, etc. It is critical to note that the project consciously address
the “I”s balancing the unnecessary slowdown but mitigate any derailment to a
project by misinforming a stakeholder.
|
Monday, June 30, 2014
RACI: An important tool to manage project outcome and stakeholder expectations
Role
|
Description
|
Stakeholder
|
Responsible
|
The individual performing an
activity.
|
This person does the work. It may be a developer, tester, data
analyst, or network administrator in software development or a project
manager in a project.
|
Accountable
|
The individual ultimately
accountable.
|
This person is answerable to the management in managing the client and
the project’s profitability. An account manager, product manager, project
manager, executive sponsor, functional manager are all examples. This person
should also use risk register effectively by mapping the risk owner to the
RACI.
|
Consulted
|
The individual required to
offer input and contribute to the activity.
|
This person offers 2-way communication and is the expert. This person
should hold both “Responsible” and “Accountable” person in check and uses the
risk management strategies. May be able to roll up the sleeves to actually do
what these above roles should do. Can take on the roles of Director,
Proposition Manager, Business Analyst, Project Manager, etc.
|
Informed
|
The individual that needs to be informed of
the decision and its impact.
|
These are the people that PMBOK calls as stakeholders that can be
positively or negatively impacted by the project’s outcome. These stakeholders
must be managed so that unnecessary escalation and project derailment does not
happen. The “Informed” is not limited
to organizational employees and business units but customers, vendors,
partners, and end-users depending upon project’s or product’s goals.
|
Saturday, May 31, 2014
Effective Virtual Meetings
Today's project environments face a unique challenge in holding effective meetings that contain team members physically absent due to geographic limitations spanning multiple timezones. Let us peel the layers of effective meetings.
First, it is critical to understand the cost of meetings. Meetings are one of the easiest means to erode profit margins and consume productive hours ineffectively if used inaccurately. For instance, putting 8 people in a room for 1 hour for project status meeting would mean 8 hours or 1 productive day of a full time employee is quickly consumed. When the idea of project management evolved in the corporate world a dew decades back, more people were inexperienced working in project environments justifying the need for project meetings. But with the evolution of project management, removal of hierarchical decision making layers with flatter organizations, sophistication of many tools in today's world question project managers calling for unnecessary meetings. This is an indication of several causes not limited to the project management inefficiency, lack of knowledge dissemination, and communication bottlenecks.
The practices of management by walking around (MBWA) has been known for a long time where key decision managers such as the project manager shouldn't be confining themselves to cubicles or office spaces but walk around to get the updates and remove the impediments faster. The agile approaches take this planning a couple of steps higher where the daily stand up meeting is used to plan for corrective actions for the coach. so, use meetings effectively and call for meetings only with members as required. Don't call for a meeting because you don't know the answer and want to show control by bringing many to the table to get the answers to avoid project derailment.
Second, now that we have addressed quickly to eliminate unnecessary meetings, let us look at distributed team members that lack non-verbal clues. These meetings further go beyond an actionable agenda with enough time for team members to review any required information to be prepared for the meeting. Some norms need to exist to understand time and culture boundaries. People may take the calls from vehicles and home, irregular hours for some participants, etc. So, muting phones unless talking, ensuring technology clashes such as not using computer microphones creating background echoes, avoiding too many parameters like conference id, password, audio key, etc besides dialing into the bridge making it difficult for people to take the call from moving vehicles, understanding constraints with the number of ports available for group meeting, and differentiating webinar versus group meetings where one person alone can talk versus many can talk at the same time are all some examples of additional meeting etiquettes.
These supplement the known order in which people introduce themselves. For instance, people can name the next person to talk, share input, or introduce.
Third, in these meetings, it is equally important to avoid the pretense of multitasking. While it is a good idea to request to repeat or paraphrase questions and is perfectly understandable in a multicultural team membership, it is not an excuse for not focusing during the meeting.
Fourth, a project manager should really understand the purpose of the meeting. An agenda is only good if we stick to it. While we don't need to go with the same order of the agenda, it is critical to ensure we don't go on a tangent moving away from the meeting's purpose.
Finally, a meeting without the meeting minutes documenting the decisions made to avoid further meetings or actions identified on who should do what by when question the productivity of such meetings. A project manager in these cases should become a good facilitator, leader, and coach to keep the meeting in focus, document notes, and coach the team towards effective meetings.
So, meet effectively and only when required. Would you agree?
Wednesday, April 30, 2014
Key Performance Indicator must start with business need
- Business Need & Effectiveness (Objectives and Key Results [OKR] comes here)
- Business Process & Engagement (Critical Success Factors [CSF] comes here)
- Delivery and Operational Efficiency (Key Performance Indicators [KPI] comes here)
- Schedule Variance and/or Schedule Performance Index
- Cost Variance and/or Cost Performance Index
- Number/Percentage of Projects Forecasted to Launched
- Number/Percentage of milestones reached/missed by project
- Number of FTE hours / project in a delivery based schedule (no resource leveling)
- % of projects coming behind schedule
- Defect Density (Number of defects logged against requirements)
- % of failure rate against test cases
- % of test cases/requirements coverage
- Number of risks against requirements/test cases
- Prioritization of requirements/test cases based on risks
- Task Progress (against DoD)
- Extent of ATDD/BDD by Business Users (e.g.: exploratory tests)
- Number of Escaped Defects
- DORA metrics
- Cycle Time, Lead Time, WIP
- Estimation Accuracy
- Commitment Evaluation (e.g.: Planned vs Actual Velocity)
- Backlog Growth and Burn rate
- Risk Reduction Rate (Identified, Treated by Response Type, Residual)
- % projects on budget
- % of Challenging Projects/Program or Portfolio
- % of Change Orders $ to original SOW $
- Internal Rate of Return
- Net Present Value
- Payback Period
- Net Profit Margin
- Capacity Utilization Rate (e.g.: Profitability per Project Management Resource)
- Account Growth Revenue
- Cash Conversion Rate (Revenue Recognition Frequency)
- Concept to Cash Cycle Time
- Marketing Metrics
- % of Complaints over Product/Program
- Customer Satisfaction Index (e.g.: NPS)
- Training Efficiency
Sunday, March 30, 2014
Enhancing Productivity
- Non-Project Hours – Delivering no value to project but time for internal process enhances, functional department meetings, training, company meetings
- Non-Productive Hours – Time lost due to ambiguous work, lost work requests, unnecessary meetings, doing other’s work, assumption about roles, lack of accountability, etc.
Friday, February 28, 2014
Ingredients of a Transformational Leader-What can you do?
2 Do you feel like you have a role or a job?
3. What have you done to make a member exceed their abilities and grow their skills?
4. What makes others reach out to you?
5. What do you know of the individual’s career goals?
Transformational Leadership Category
|
Some Thoughts – Actionable steps
|
Ideal Influence
|
1. Walk the talk and avoid lip service. Let the results speak to your
efforts.
2. Build trust for the team by “being there” for them and modifying
people’s behavior to embrace change
3. Proactively implement new ways to organizational culture
|
Inspirational Motivation
|
1. Learn what motivates people – extrinsic and intrinsic needs.
2. Learn from failure so that future strategies can avoid risk and
improve quality
3. Maximize learning from success so that these are not accidental outcomes but repeatable outcomes
4. Ask how you contribute to the organizational vision and empower them
for change.
|
Individual Considerations
|
1. Give work assignments to match one’s skills but challenge you to grow
them by pushing them out of comfort zone. Be a servant leader – they may not
how it benefits them always.
2. Consciously build a career plan. You owe it to your team even in a
balanced matrix organization by providing recommendations.
|
Intellectual Stimulation
|
1. Foster Creativity & Innovation - If the wheel is not broken,
then, you haven't looked hard enough.
2. If people agree too often with you, ask yourself if you are
surrounded by "yes" men.
|
Henry Ford once said, “Coming together is beginning; keeping together is progress; working together is success.” To me success is a meeting point between preparation and opportunity. We need to prepare ourselves to lead before an opportunity presents itself. Understanding one’s own drive and emotions is instrumental to understand the others, which is a perquisite for the transformational leadership that is practiced every day with effective habits on us first before they can be practiced on others.
Are there any other actionable steps or questions that can make this list more comprehensive for practice?