Tuesday, August 30, 2016
Sunday, July 31, 2016
I was volunteering at the #Agile2016 conference this week in Atlanta, Georgia and had an opportunity to support another volunteer friend who was trying to organize an open space session. What was so impressing was this friend's willingness to get over the comfort zone to get in front of a crowd to facilitate this session with the only goal to creating a stickiness of the information gained from attending the conference to others. It was so wonderful to see how this friend exemplified servant leadership forming a habit to facilitate this session.
Marshal Goldsmith (2007) published one of the classic book where he advanced 20 habits for fast forwarding one's career by identifying habits that may be bringing themselves down creating trust erosion in the team. These behavioral traits may be in our own blind spots that we may easily fail to recognize how we are are sowing the inappropriate seeds for our own professional growth while simultaneously bringing the team down. Joshua Arnold (2016) referred to some of these behavioral traits as HiPPO (HIghest Paid Person's Opinion) in one of this presentation at the Agile 2016 conference. Readers are advised to check this classic to get more insights.
It was a classic example for me to see in action how one individual took the initiative to form a habit not only to benefit from his own reading of a classic book but also push the individual limits to get over the stage fear because of the belief that there was something he had the world should know to benefit from. Now, servant leadership is exactly that - leading with others in mind encouraging the drive to excel, acting with humility, and strategically advancing long term benefits over short term quick wins.
This friend proposed the idea at the open space session providing an elevator pitch creating an interest for about a dozen people as he described the 20 habits creating an activity for people to form a group and select one of the habits that resonated with them in groups, create visual images of these habits, and identifying strategies on the impact of this habit and recommendations to eliminate this habit. The amount of time this friend spent at evenings and nights to form the elevator pitch and create stickiness for anyone that may come for his open space session applying the techniques suggested by Laura Powers (2016) really hit a home-run as the attendees to the session appreciated the new packaging on these habits as they emphasized how this session helped them. I was so glad to be part of supporting him in his endeavors.
As I continued to support this friend in this session, I really renewed my own interest in the coaching of such down-to-earth individuals who not only try to improve themselves but attempt to leave the world in a better place than they found it by avoiding excuses. As Carrie Kish and Jurgen Apelo pointed in the various leadership stages of genius tribes and managing for happiness respectively in their keynote address, it is the knowledge that we gain from such selfless individuals and their friendship that makes
What are we doing today to get ourselves out of any comfort zone that we have encapsulated ourselves in advancing the great experience and knowledge that we have gained?
Arnold, J. (2016). How to train your HiPPO. Atlanta, GA: Agile Alliance.
Goldsmith, M. (2007). What got you here won't get you there. New York, NY: Hyperion Books.
Kish, C. (2016). Leadership for genius tribes. Atlanta, GA: Agile Alliance.
Jurgen, A. (2016). Managing for happiness. Atlanta, GA: Agile Alliance.
Powers, L. (2016). The neurology of learning: Your brain on agile games. Atlanta, GA: Agile Alliance.
Thursday, June 30, 2016
1. Manage meetings
There is a lot of practical literature around how to run effective meetings. Instead of going into microscopic details on meeting management, can we not focus on ensuring that every meeting has a clear outcome to accomplish at the end of the meeting? Whether it is 15 min or a day long meeting, having a clear outline of planned outcome will establish evaluating the necessity of the meeting in the first place. Not having a meeting unnecessarily or accomplishing meeting objectives earlier releases so much time that could be used for other productive tasks.
This is where agile thrives because it timeboxes all ceremonies and avoids meetings not necessary. Project and Program Management can also apply the same techniques.
2. Correct your course
Whether it is running meeting or managing the client, things don't always go the way you plan! So, plan for course correction? What's the point in all these "Failing to plan means planning to fail" when we fail to apply it in principle! When a meeting goes on a tangent, correct your course by bringing attention to your outline. When customer requests come out that emphasize lack of understanding or you get a project where you don't know the underpinning the technology, make course corrections yourself by taking an initiative to learn the technology!
In the world of Khan academy, Plural Sites, Course Era, Open2Study, Bright Talk, and so many other MOOC - not to mention YouTube or Vimeo - there is plenty of information available already for people to gather information! So, correcting your own course is totally on you and not doing so is actually taking the team's time away!
Here is also an approach from Agile where there is retrospective at the end of every iteration! Did traditional approaches ask not to have frequent lessons learned sessions? Absolutely not! It is a restriction that project management forced themselves on and the management failed to react to it. In other words, they chose to learn from the lessons and hence succumb to failure!
3. Focus on Training on "Done" criteria
Having a constant baggage on the trunk actually creates so much drag in an automobile which slows the automobile and burns unnecessary fuel! That's why we don't drive - at least technically - with unnecessary baggage, right! Doesn't that principle teach us to focus on getting tasks completed! Coming from lean management philosophy, it is a principle of waste in over-engineering anything to the point that it is not getting done! So, project management can extend these principles to apply simple heuristics in managing their WBS or have user stories that apply the INVEST principle.
In my experience, I have always applied the golden rule of no task having a duration longer than the risk that I can live with the task completing. Most often, no tasks are longer than 40 days and some work package is always getting delivered every two weeks. So, milestones are not 3 months apart! Such thinking still applies earned value principles to make course corrections if a project slips!
Here is where the INVEST principle from agile comes to help where every user story is independent, negotiable, valuable, estimable, small, and testable! So, don't add tasks just for the sake of adding and use the hammock tasks productively.
4. Establish Stretch goals
No matter how much one knows, there is always room for improvement! This is one of the reasons change management principles advocate continuous improvement. The self-organizing theme behind teams in agile setting really ensures that team members are adequately skilled cross-functionally to pick up other people's task to support the sprint commitment! In a traditional setting, we create unnecessary layers. Every team in a traditional setting should have a stretch goal to learn another team's work and practice. Not only does this avoid central dependency on another, it also helps appreciate the tricks of trade and appreciate the service level agreements and standard operating procedure enhancing adherence to protocols. It also lets creative juices flow as one challenges the status quo to do things differently! Only by learning more does an individual become part of a group and evolve to be a self-organized team.
5. Use the tools of communication effectively
Although we all appreciate a wrench and hammer have their distinct purposes, we also realize overly abusing the tools for the wrong purposes damages what we are trying to accomplish more than the tool itself. The same analogy goes with the tools. I wish we can monitor the use of the "Reply to all" button that creates so much email for an organization. People reviewing the emails out of sequence, replying to them in random order understanding parts of pieces, and eventually ignoring it will only cause so much productivity loss - time that can be used for other productive tasks. So, learn to manage by walking around, collaborating using better tools, and avoiding creating so much electronic dialogue that provides no clear documented decision making.
In my experience, these simple techniques have helped build constant productivity regardless of the approach. In the end, what matters is only the results.
Tuesday, May 31, 2016
Maximization of value means within the agreed timebox, the team self-organizes to add the appropriate tasks. The scrum master acting on the team’s behalf needs to hold the definition of done articulated ambiguously by the product owner. Similarly, the product owner needs to be held accountable to the larger committed timeline to the customer not losing focus on the slips in the timeline due to losing velocity in every sprint. The scrum master needs to hold the product owner responsible for capacity planning in a velocity driven team rather than a commitment driven team.
Friday, April 29, 2016
Project Management - Mindset Change (2016, April). Palagai, 1, 8-9.
Thursday, March 31, 2016
Monday, February 29, 2016
- Has the contracted scope of deliverable been met? If not, why?
- How efficiently were the project objectives been delivered?
- How effectively the project stayed on schedule? If not, what contributed to the delays and what processes need to be in check to avoid future schedule slips?
- How well the project management proactively forecasted changes and adjusted the estimation process?
- How satisfied are customers and project stakeholders?
- How did the actual compared to the final baseline plan?
- How did resource availability changes impact the delivery to adjust for capacity planning?
- Did the team work together effectively?
- What individual contributions positively or adversely impacted the project’s quality? How was performance expectations managed?
- What attempts were made to strategically manage the customer?
- Did any work start late and if so why?
- What improvements have to be made on an individual, team, and process levels to positively impact future projects?
Sunday, January 31, 2016
Wednesday, December 30, 2015
- Is starting immediately with a “No” a good approach?
- When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
- Are both the client facing person and the project manager on the same team as the expert?
- Were any attempts made to negotiate for a acceptable best alternatives?
- Is this project setup to succeed?
- Is this a productive meeting?
Monday, November 30, 2015
- Opportunity cost of the existing status quo relative to the alternative arrangement
- Impact of the alternative arrangement on the immediate needs that caused the dispute
- Timely feasibility of executing the alternate arrangement
- Risk of the alternative arrangement not providing the promises relative to the status quo
- Evaluating the risk profile and thresholds of the appropriate stakeholders who can be enablers of the best alternative
Saturday, October 31, 2015
- P - Passion about people. Project management is all about people management. This is where the transformational leadership elements of a project manager is displayed.
- R – Resourceful around Risk management. Seeing proactively the risks and managing them by maximizing opportunities and minimizing threats
- O - Organized around self to manage all aspects of the project. As the saying goes, if you can’t manage yourself, you can’t manage the people that do not work you in the project.
- J - Justified in constant review of resource utilization including both the human and non-human resources keeping in mind the total cost of ownership on the project managing scope and quality
- E - Effective in leading change seeing it as a vehicle to improve scalability and as a liaison to other business units within the performing and client organization
- C - Collaborative in bringing ideas together letting the individuals become groups and then evolve as teams to support each other
- T - Trust worthy to transform people’s career. This completes the cycle of project where one’s passion for people makes them a servant leader.
Wednesday, September 30, 2015
The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents, sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the characteristics of a user story. Even test cases that focuses on negative testing uses a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.
But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?
While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee who could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for mal-intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the spee of password entry, etc. Imagine having such stories to bullet proof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.
I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, similar to non-functional stories that add some time, the abuser stories also will add time. The need to develop hinches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However, the question shouldn't be whether to do them or not but when to do them. If we fail to do them we are increasing the technical debt. A couple of alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.
I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project mangers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.