Search This Blog


Thursday, April 30, 2015

What is a successful meeting?

Meetings are everywhere.  External meetings, internal meetings, individual meetings, group meetings,  team meetings, daily sprints, sprint reviews, retrospectives, etc.

Often, people claim a meeting is successful. There are meeting notes distributed too. But, what determines a successful meeting? I am not focusing in conducting an effective meeting on meeting etiquette but evaluating the success of a meeting.

I recall a great book on How I raised successfully from failure to success in selling that gave the tip. A successful meeting is one that has the next meeting identified.  But, wait a minute, is that it? So, if recurring meetings are set, then isn't all meetings successful?

There lies the myth. The successful meeting is the one need having clear action items identified with action owners and due dates so that the next meeting serves as a follow up. The follow through happens in between these two meetings ensuring incremental and iterative progress closing the sale, improving processes, updating progress, identifying risks, lessons learned, and removing obstacles.

If follow up meetings are proving to be action owners not providing updates or providing vague updates, then it is time to evaluate if the right owner was identified or if the owner is capable and having bandwidth. Identify escalation paths if necessary. Of course, this is true when that action item is still applicable.  If a solution is identified or closure is recommended,  then it is also important to ensure collaborative commitment and if any additional follow up would be required now or later.

Would you look at your meetings and evaluate if your meetings are successful?  What other criteria would you add outside of meeting etiquette to evaluate the outcome of a meeting?

Monday, March 30, 2015

Value of Microsoft Project Schedule in Agile Environment

One of the biggest wars in today’s software development community is the choice to use Microsoft Project Plan. In a traditional plan driven approach, the value of Microsoft project plan to know the higher level milestones, traceability of hammock, resource leveling, earned value, project and resource calendar, unit of work, impact of delay, critical chain versus critical path, network analysis, early/late start/finish, lead/lag discussions, and multi-project/program dependency are all very well understood. 

But, when you turn the attention to agile, the story shifts! Agile focuses fundamentally on self organized teams that manage their own tasks who are empowered to try different approaches. This is one of the reasons why the Scrum methodology doesn’t even mention a project manager role but only the scrum master role and product owner roles. But, in a true agile environment, or a matured scrum practice, the team is almost on an auto-pilot! The only two needs for the team are to get the clear direction and business need on what features to develop (product owner) and the support to keep deviations minimum to work on the delivery (scrum master).

But, how often are the teams so self-reliant that they think of the feature outside of their business unit as a whole on the delivery? When the team is depending on the other leaders to drive this priority, interface with the product development to provide the clear direction (business need and business impact) among other things, the project manager role emerges again.  If this need exists, then, what’s the question behind the MS Project in agile methodology?

Let us think from agility. The goal of Agility is focus on burn rate and velocity. These are good key performance indicators (KPI) in agile world in a product development setting. For instance, if we have 500 story point worth of user stories with each sprint taking up ~50 stories over 2 weeks, then, at the end of 10 iterations (discounting the hardening iteration), we expect all features to be completed. Now, say at the end of third sprint (6 weeks have gone), you are at 120 story points. We use the velocity to look for patterns in what types of commitment can be delivered by this agile team or the burn rate to project when the project can be delivered. The project managers that understand the earned value management (EVM) principles can utilize planned value, earned value, and actual cost to analyze patterns. Properly utilized, these values can come directly out of the Microsoft Project Plan even in the absence of a Project Management Information System (PMIS).

If the individual iterations are a major milestone with additional hammock activities focusing on specific user stories, then, the Microsoft Project can still be a value added tool for the project manager to use in an agile setting. In such cases, if required, the Project Manager can still limit the focus only to the user story level tracking and should the user story become a show stopper (DONE criteria not going to be met), then, it is possible to move this story to subsequent release. Using MS Project, still commitment planning can be forecasted better. Using project reports and earned value techniques, one can do similar analysis as velocity tracking and burn rate!

The tool is only a means to accomplishing the work. If simple Excel or white board can be used for Agile tracking, then, to discard such a power-loaded tool as a non-agile tool is a premature exclusion of the tool without considering its benefits.


Saturday, February 28, 2015

Choosing between agile versus plan driven approach

Increasingly, I keep hearing to references like the challenges and benefits to waterfall approach versus agile approach to software development. Whether these are software developers, testers, technical operations, project management, or sales & marketing professionals, the underlying theme is that software development life cycle (SDLC) has become synonymous with waterfall development but agile is not. Focusing on the core principles of agile, primarily ‘working software versus comprehensive documentation’, isn’t agile approach also developing a software? Aren’t the concepts of planning at various layers, such as daily, iteration or sprint, and release, to iteratively develop incremental software enhancements part of a life cycle for software development? So, where is the huge disconnect?

The challenge is not in the approaches but in people’s incorrect assumptions in thinking what the original SDLC proposition was and equating it to waterfall. In fact, in a recent meeting that I attended in PMI Mass chapter, many participants didn’t relate to the original author of SDLC, Winston Royce’s seminal proposition in 1970 who himself related to the challenges promoting incremental and iterative approach and the increasing involvement from project management in software development. Practitioners therefore created a non-existent and non-functional theory of waterfall embedded with the assumptions below that are challenged by an article located at

1.       Linear approach to software development with no feedback
2.       Big upfront requirements gathering
3.       Gathering requirements upfront saves cost
4.       Analysis follows requirements followed by design
5.       Project Management is not part of software development
6.       High degree of documentation needed before starting work
7.       Customer sees work after all the work is developed and tested
8.       Testers need not be involved early

Therefore, I will deviate from using the word, “waterfall” or “traditional” approach and recommend using the “plan driven development” using the rapid application development and fundamental project management principles. Basically, the requirements for the choice of agile or plan driven approach to software development lies in the problem being solved. 

If the challenge is to build a mission critical application controlling the amount of x-ray radiation that will be discharged by a software application, then, a plan driven approach may be a better fit because of the certainty in requirements that can be reasonably predicted and the amount risk involved in doing it incorrectly without impacting the profit margin. On the other hand, if the requirements are not certain and the complexity is not high where the functionality is possible to release in an iterative fashion such as a new mobile application or responsive website for student enrollment in a college, then, agile may be a better candidate. 

So, instead of choosing the methodology and solve the problem using the methodology, the methodology has to be chosen based on the problem solved!


Saturday, January 31, 2015

Risk Managemeent: Key to Advancing into Program Management

The Project Management Institute (PMI) introduced the principles behind program management with a critical focus on maximizing benefits.  Often project management focuses on controlling scope and schedule using available work flow tools that they miss an important component of not understanding the value of the project on a larger scale.

The question to ask here is what role did the project do in increasing the value to the performing organization, customer,  and the society?  When we think about this and focus on the benefits,  we step into the next stage of ensuring the project risk is constantly monitored.  There are various tools to managing the risk but constantly keeping focus and most importantly the risk register.

Understanding these risks is a critical element to the next stage called program management.  Why? This is because the program management focuses on what an individual project can't deliver. The impact on value maximization is high in program management a if the risk is not more actively monitored.  There will be too many interproject dependencies that may impact this projects higher. So, when advancing to program management,  active risk management is critical and is a sine qua non for project management excellence.

Wednesday, December 31, 2014

Acceptance Testing: Demystified from a business perspective

Recently in building a RACI diagram, I found questions bubbling up on why acceptance testing must be done and why that’s testing group’s responsibility. I find it interesting to see how the responsibilities have morphed over the period on the roles and responsibilities associated with testing that I felt compelled to write this blog article with the illustration below.

When developers write the code, the code should be error free complying with the low level design. Since most of the code today is conceived and written in a modular fashion, thanks to object oriented analysis and design thinking, the unit testing done at this level is focused on individual modular units. Examples would be to check for memory leak, the use of uninitialized variables, etc. As several modules are consolidated within the package, the need to ensure the modules integrate at a higher design level comes calling for integration testing. Examples would be the passing of data between modules in a meaningful way, the use of calling external databases or webservices to ensure that there is adequate time given for timeout and exceptions so that the integrated code gracefully handles the situations. These types of testing are integral to the white box testing still at the engineering or development side focusing on the internal structure and design of the program rather than the functionality of the program.

Subsequently, the build (note that I am not using the word code) is transferred to the testers who check the workings of the program to the specifications. These testers still have some intimate technical knowledge, understanding of the database to write SQL queries or check webservices methods, write test scripts, etc. For custom projects, this group ensures conformance to requirements. This type of testing is part of the grey-box testing because the testers test for specifications but have additional access to tools for technical validation. They assure that the quality of the software agrees with the requirements agreed upon in the user stories or in the business requirements documents (BRDs). Here is where the gap begins within the management community.

Those that are familiar with Juran’s definition (the seminal though leader that laid foundation of software quality) also will relate to the need for “fitness for use” as another ingredient of quality assurance. Nobody other than the customer can actually evaluate this fitness test which is where the user acceptance testing (UAT) evolved. But, think about how the transfer of ownership is executed in an organization. There is inexorably communication from project or account managers in custom software development or product owners in the product development to customers that the software is ready for their UAT. This is where these business owners should be held responsible to execute black-box testing evaluating at a higher level and satisfying themselves that the software is working to the customer’s requirements. This is the last window of opportunity to identify any escaped defects before the actual customer gets involved in interfacing with the software. Then, any escaped defects the customers and end users find or new feature enhancements identified are gathered in product backlog grooming, risk adjusted for priority, and accommodated in the subsequent iterations.

This level of acceptance testing is slowly and steadily disappearing from project, program, account, and product owners leaving the image of the performing organization at risk in front of the customer leading to trust erosion. Every car goes through a lot of quality checks but still when we buy a car, we take it for a test drive. Why shouldn’t we test drive the software ourselves before we give it to our customers? 

Sunday, November 30, 2014

Cost of Quality: The increasing value of acceptance testing besides automated testing

There are two prevalent themes in software development in the corporate world: “Zero Quality Errors” and “Doing more with less”. The dominance of both these concepts has critical importance in their implementation.

  1. 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.
  2. 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 logical solution is “Automated testing” making the system do testing detecting more defects at earlier points in the development life cycle as well as continuously testing deployed code for production bugs. The solution is definitely logical and practical as it accomplishes doing more work with fewer resources consistently, continuously, and almost effortlessly compared to the needs to have a human present to manually test. 

Does that mean automated testing is a perfect solution where we can enable computer assisted software tools (CAST) to as many testers as possible? The agile engineering practices recommend automated testing but also emphasize acceptance testing where the business owners also are involved in testing. But, how far our people in client-facing roles like product managers, project managers, program managers, and account managers increasing their knowledge of the business domain and related technical tools to test the releases?  How much is the management attuned to this fact?

  1. 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?
  2. 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?
  3. 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.

If quality were a coin, automation testing and acceptance testing are its two sides. Efforts spent only one side won’t make the completely desired economic impact.  Automation is a shift in the way the code is developed, tested, deployed, and monitored requiring refined skills. It is an important element of reducing the cost of quality but so is the acceptance testing that requires additional skills. If we fail to recognize and implement both these effectively, then, the efforts spent in automation may be offset by escaped defects due to lack of acceptance testing.  A new breed of client facing roles is therefore on the raise and the management needs to focus on both the automation testing along with acceptance testing. 

Friday, October 31, 2014

Adapting Scrumban to Personal Productivity

Agile approaches to product development and project management are growing exponentially. I have been a proponent of the lean approaches even at my house chores and recently found that such approaches were discussing even in the Agile 2014 conferences. Unlike Scrum’s requirements to have self organized teams with timeboxed iterations within which changes are generally frozen and disallowed, the project management approaches do not rejoice the dedicated team. Often, the members may be spread across multiple projects similar to project managers having multiple projects. So, how do we manage time effectively in multi-project and program initiatives?

An approach that I have found useful is adopting Scrumban to proactively manage myself and build on the team’s innate strengths to empower themselves to do better. Sounds great, but how? Let me explain.

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

In traditional project management where resources are not procured for the duration of the project or in balanced matrix organizations where projects inherently face wait times, such as in regulated and construction industries, the project team may not be multi-functional. Therefore, it is not possible for any member of the project team to take on any project or tasks within the project. For instance, can a tester write code? Can a database architect develop deployment requirements? Can a project manager be a business analyst? While technically these are all possible in high performing organizations, other organizations may not have resources that have multitude of skills where roles can be effectively merged eliminating waste.

Here is where Scrumban comes to help. It combines the best of both the Scrum and Kanban worlds. Tasks become fairly structured (design a program overview, develop the stored procedure, test interactive voice response for a specific Voice XML flow, etc.) to be executed by anyone within a specific group. The group or functional leader is entitled to provide the guidelines and process direction for continuous improvement reducing cycle time increasing predictability in productivity. Example, regardless of who develops the program or tests the campaign, in the given service level agreement of 5 days, the program will be developed or tested. Yet, workflow need not be limited changes only between iterations thereby allowing new tasks to be created eliminating wait time and allowing the team to prioritize projects.

While Scrumban is great alternative where neither Scrum nor Kanban can be effectively applied, I found out that I can use it to manage myself to be productive better in multi-project, program, and portfolio management. I have illustrated this in the above figure. From my point of view, the team is the expert and I am just a facilitator. So, when the team has been provided a task, it is in progress (Yellow sticky). Now, what am I doing when the team is working on it?

I don’t need to hold a meeting to check on progress – that’s project management by unnecessary meetings. But, I shift my gears to what the team may be requiring next – eliminating all ambiguity for the potential next task. As a project manager, I focus on the upcoming milestone working a step proactively ahead (Blue sticky) and work with the stakeholders to get that ready so that when the work in progress is done, I am servicing the team with the next unambiguous task. This comes in handy when the team is virtually distributed because in such cases where communication needs to be both pull- and push forms, I got time to over-communicate! This is an example of what I label as 6P principle (Proper proactive planning prevents poor performance!)

Now, the more I work at this the more effective I become and so I work another step – 2 steps ahead – and work with the client, product, account or other teams to push them to deliver on their deliverable ahead so that there is no impact to critical path (Green sticky). I stop at 2 steps only because in my mind I am 1 sprint ahead and my agility hat tells that there may be change coming that I need to prepare for.

Let us take it to the next level. May be the green sticky (Product, account, client, or other teams) can’t do anything because they are waiting on something else. Then, so much of time becomes unfrozen. Immediately, that means productive hours can be provided to another project. This is an approach to doing more with less. This next project could be part of the same program, product, portfolio or a totally different project for a different client or even developing a hobby, helping another team member, writing this article, or dedicating time for a cause. 

This is an approach I have used to timebox all the incoming work so that within the given time available, I am still able to keep multiple things moving!