Tag: Team

Your Agile Might be Fake

Written by Paul Oppong on July 3, 2019. Posted in Articles.

“Agile” is a term commonly used in organisations of all shapes and sizes these days.

When I go into organisations, I hear leaders saying, “We use agile”, yet digging deeper, I find things aren’t quite, well, agile, in fact sometimes not at all. A fake idea of agile implementation is commonplace, and managers say the agile words without really understanding the principles and concepts behind them. This means that the team is not truly agile at all, and not reaping the rewards of being agile either. But what does fake agile look like, and how can this be diagnosed in an organisation?

Symptoms and Signs of “Fake Agile”

There are numerous signs and symptoms that an organisation is not being genuinely agile. One of the most common is perhaps the idea that a team can take the elements of agile that they like and use only these, discarding the rest. People who have implemented this approach will make comments saying that they use agile techniques while then going on to say, “Well, it’s not quite agile, we used what we liked from a few different models.”

Another common challenge is not really understanding the core concepts of agile, while still believing the team is working within them. For example, agile is fast, meetings should be fairly quick, while covering the activities of yesterday and today, and discussing barriers. The idea of a daily Stand-up meeting for instance in a Scrum or Kanban agile implementation is to keep it concise and to the point. Some teams find they are having stand-ups that last multiple hours. This indicates the agile implementation might be what it is meant to be and not really working. It might mean that the meeting probably has too many attendees, and in which case it might be possible to work in smaller groups instead. Alternatively it can mean the team is working in a hierarchical manner, which is not the point of agile.

When a team is truly agile it will continuously deliver value to customers. This is a critical underpinning principle of agile. The reason for introducing this concept to agile, was that in the past, developers would work on a project for months, deliver it to the end customer, and by the time it was delivered, requirements would have moved on, or it would not do quite what the customer needed. This means that there is a need to understand customer needs throughout the development process. This is an idea that agile is built around, and hence the principle of continuously delivering value. This leads to the ability to pinpoint other clear indicators of fake agile. It follows that if teams are not securing feedback from customers regularly, and looking at it quickly, then they are not continuously delivering value to them. Feedback is a regular and integral part of agile. What is more, if no time or money is budgeted for change to the project then the team is probably not agile. This is because continuously providing value will invariably require looking at ways to change the development, so it more closely aligns with customer needs, once feedback is received.

Three Key Questions to Diagnose “Fake Agile”

There are some questions that can be posed to those leading so-called agile programs to determine if they really are embracing agile concepts. You might ask, “Do real users see iterative working version of the product, and if so, how often?” If the answer is no, agile is not in place. It is also a problem if customers only see iterations every few months. This is not agile project management either. The end users should be seeing and feeding back on iterations with regularity.

Another question that you could ask is, “How frequently is feedback from users converted into work activities for teams?” If the answer is never, the team is clearly not agile. If the leader responds that this happens within time frames of less than one month, then it is possible that agile is operating as it should. After all, as we have seen above, agile operating is all about meeting customer requirements by taking on board feedback and incorporating it into the project.

A third key question to ask is about team empowerment. You may ask, “What level of empowerment do team members have? Can they change processes and requirements based on user feedback and on what they learn?” Empowerment of team members is a core principle of agile operating. Leaders that say any answer that includes, “Yes they are empowered but…” are probably not following agile methodology. Any indication of hierarchical, top-down decision making goes against the agile way of working.

Summary

Many business leaders think they are being agile. They also like to say it, because agile is a popular buzz word. That does not mean they actually are agile. Any so-called “agile” approach that just takes the parts of agile the leader likes and ignores the rest is not truly agile. Underlying agile is fast, iterative development, with feedback taken on board along the way, to continuously deliver value to customers. Where an “agile” solution does not do this – beware! It is almost certainly going to be fake agile.

Yet another enquiry to make is whether the whole project operation is agile. This will help pick out those leaders that think they have got the best of both worlds by using some agile principles combined with other more traditional forms of project management because these are more palatable with their idea of control and command. If the answer is no, then the team is not working in an agile manner. In fact, if the answer is “Partly”, this is also still true. When agile teams work in an agile way to start with, and then use bureaucracy later on in the process, this is not agile operating. The only correct answer to this type of question is, “Yes” without any caveats being applied.

Approaching The Unapproachable

Written by Emily Doidge on June 13, 2019. Posted in Articles.

Whether we’re eliciting requirements, growing our product knowledge or attempting to understand a process, our minds are inevitably filled with a variety of questions.

As Business Analysts, we rely heavily on other people’s expertise to help answer those questions. Have you ever found yourself faced with a stakeholder, customer or colleague that’s defensive, irritable or unapproachable? If so, read on!

I had been with my company for over 10 years when we identified an organizational need for a new position, a ‘hybrid’ BA. I was excited to fill the role and was quickly brought in to help on a variety of projects. It quickly became evident that I had a lot to learn about our internal processes and procedures, not to mention what it would take to be an effective BA.

I found myself feeling overwhelmed and ineffective, which effectively drove me into research and discovery mode. As I gained knowledge and understanding, the questions formulating in my mind grew exponentially. I found myself asking, “But why?” with the frequency of a toddler. I knew who could help answer my questions, but I was continually met with resistance in the form of defensive responses, irritable tones and body language that was screaming, “DON’T YOU DARE THINK ABOUT ASKING ME ONE MORE QUESTION!”

I was desperate for answers, but faced with “the unapproachable.” After a few tense interactions that left me feeling disconcerted, I suddenly realized that I was going about these conversations in the wrong way. I knew that if I didn’t take the initiative to address the underlying issues, we would both suffer.

With that in mind, I found my courage and pulled her aside for a conversation. I shared with her the purpose of my position, why I had so many questions, what I was working on and how my questions directly impacted her. In addition, I apologized for neglecting to provide her with context up front.

Her body language changed almost immediately and that prompted an engaging dialogue that instantly changed our relationship. The conversation unveiled areas where we could both do things differently and brought a level of awareness that I hadn’t anticipated. As I left the conference room, I found myself feeling empowered with a renewed sense of confidence and self-awareness.

The best part? We have such a healthy relationship now that I asked for her input on this article.

In the midst of our conflict, I identified a few key areas that I could improve on. If you’re struggling to communicate effectively with a stakeholder, customer or colleague, consider these suggestions:

Provide Context

We identified that a lack of context was the root cause of our conflict. I repeatedly made assumptions that she knew why I was asking questions and how they fit into a bigger picture. I wasn’t providing context and instead, peppered her with questions and assumed she could connect the dots. Needless to say, my elicitation technique needed some refining.

I neglected to use Stephen Covey’s insightful words, “Begin with the end in mind.” If we can’t articulate why we need the information, how we intend to use it or where it fits in the bigger picture, then maybe we aren’t ready to ask the question. She wanted me to explain where we were going or what the goal was, but I was so focused on my need for output that I didn’t realize I was missing a crucial step.

I like to think of context as an opportunity to collaborate. We have a chance to share our viewpoints and listen to theirs. Many times, their perspective can help us form connections and associations that we would otherwise overlook.

Context and collaboration combine beautifully; use this as an opportunity to learn from one another!

Convey Confidence

I found myself starting conversations by saying, “I’m sorry, I’ve got a question for you.” By starting with an apology, I was discrediting myself and the validity of my questions.

In her book, “The Power of an Apology,” Beverly Engel says that over-apologizing can actually send the message that you lack confidence. Resist the temptation to feed into the other person’s behavior and instead, convey confidence (even if you don’t feel it). This sets the tone for the rest of the conversation; it says that you have a purpose and that you believe in the value you bring.

If you don’t believe in yourself or your mission, why should they?

Practice Empathy

In the midst of our conflict, I found myself mirroring her defensive behavior. Even though it’s a common self-preservation technique, it wasn’t constructive. I felt the need to be on-point so that I could have a response ready, but that meant I wasn’t really listening.

One of my favorite quotes is, “Listen with the intent to understand, not respond.” This is really what practicing empathy is all about. If we listen intently, we move toward a place of understanding, where we have the opportunity to experience the other person’s thoughts and feelings. Take the time to validate their emotions. Validation doesn’t necessarily mean agreement; it’s acknowledging that they’re entitled to their feelings.

If you aren’t sure where to begin, consider starting by asking clear, open-ended questions and then listen with purpose as they share their perspective. If you’re unable to fully grasp or feel what they’re experiencing, request clarification. If you feel like you’re starting to understand, summarize what they said in your own words to ensure you’re on the right track. As a hands-on learner, I also find that asking the other person to show me, coach me through the process or help me draw out the scenario can be incredibly helpful. Many times, the act of doing helps drive our understanding.

Empathy is all about relating on a deeper level – beyond job descriptions, positions and output – it’s about embracing our humanity!

Express Gratitude

By the time our intense conversations were wrapping up, I was usually so discombobulated and frustrated that I wouldn’t put emphasis on showing her the respect and gratitude she deserved. Instead, I would throw an aloof ‘thanks’ out before scurrying back to my desk like Gollum with his “precious.”

When someone is willing to share their knowledge, experiences, and perspectives with us, it’s a gift and we need to treat it like one.

While expressing gratitude may sound like a breeze, I’ve found that it also takes practice. Thank the other person for their time and tell them what your biggest takeaway was from the conversation. I’m notorious for getting outwardly giddy when I finally connect dots that seemingly had no connection. Share that contagious excitement with the other person because ultimately, it’s likely their information that helped you get there.

From there, consider taking gratitude one step further by following up with them, not because you need something, but so you can share how their information helped advance the project.

Build a rapport beyond “what can you do for me?” Build a meaningful relationship.

As someone who thrives on interacting with others and building relationships, I was taken aback by how quickly I became focused on what I needed to accomplish instead of cherishing the opportunity to engage with others. I love to learn but I also love to teach, challenge and witness growth in others; however, I lost sight of the relationship and instead put emphasis on the transaction.

Learn from my mistakes and consider reframing how you view your relationships. We have no control over how other people behave or respond to us. Focus less on what other people are or aren’t doing and more on what you can do to positively change your interactions. Be the change! You might be surprised how quickly people notice the shift you’ve made and respond in kind.

And maybe, like me, your unapproachable person will turn into one of the most reliable, considerate and authentic people you have the privilege to work with. What have you got to lose?

Why Common Sense is Not Good for Software Development Teams

Written by Decler Hague on March 21, 2019. Posted in Articles. 1 Comment on Why Common Sense is Not Good for Software Development Teams

Recently, I had to create an account for one of my children’s school-related matters.

Once the account was created, a token to verify the email address was sent to my email address.

Emails sent to this email address are retrieved by another email provider using the old POP3 protocol. When the email with the token arrived and I clicked the link, the requesting server replied, “The supplied token is incorrect or has expired”.

I obtained a new token but it also expired, and the next one did too and so on! The time allowed to respond was set too short for this particular POP3 scenario, which meant I was stuck between clicks, and unable to continue.

I was able to overcome the problem eventually, but the point is that during software development and testing of the account creation feature, this particular scenario was somehow overlooked. The dev team may have used, common sense or the “very rare, not worthwhile” argument to avoid doing further analysis or simply, nobody thought about it.

In this case, there were no huge consequences (only a few hairs of the few I have left were pulled out), however, in a different situation, not deriving important business scenarios from requirements, user stories or features may be a very costly oversight.

More than common sense

Agile practitioners sometimes characterise Business Analysis (BA) as nothing more than “common sense”, thus precluding any further efforts to understand important aspects of features. i.e., a customer’s real needs, and the business context where the needs are drawn from.

We claim allegiance to “customer satisfaction”, or to “improving product’s user experience”, but do we only go as far as “common sense”? Business Analysts are actually very weary if “common sense” is proposed, particularly when it is used as a means to jump into “quick solution” mode.

More often than not, ‘common sense’ only leads to lacklustre solutions, or increased development and/or testing time due to lack of understanding. Emulating the term “technical debt” used in agile dev teams we could say lack of true business understanding generates a kind of “business debt” potentially rendering a piece of software code unsuitable.

This is why BAs are not mere “problem solvers”, but far more importantly, they are “problem understand-ers”.

A wealth of BA skills can be used to explore, analyse, and understand real needs and business context. Scenario analysis, personas, customer journeys maps, and conditions of business value are some popular ones that come to mind.

The right mindset

A colleague at work recently mentioned that while “anybody can take a photo, not everybody is a photographer”. He was quite right!

Skills and the techniques by themselves are not enough to understand something. They necessary, but they are only the “what” without a sense of “how” they can be applied.

This brings to the fore an important competency of Business Analysts, namely the “BA mindset”. The BA mindset has its foundation and focus on delivering business value from accumulated knowledge and ability, and helps determine how well you can use skills and techniques in a specific situation. Just like a professional photographer.

Agile teams not only produce software, but they must also produce “valuable” software and “value” pertains to the business domain. The business domain needs to be explored and understood if we want to deliver value in the first place. That is what BAs do!

The “analysis” task within an Agile team, no matter who performs it, beyond common sense requires business analysis techniques, and the skills and competencies of business analysts. Although these can be learnt, in order to truly build a great analysis capability within Agile teams a dedicated member of that team is best, regardless of title, role or where they sit on the development team. If not a BA, a BA can coach them!

From the Sponsor’s Desk – The Nuts for Cheese Project

Written by Drew Davison on March 14, 2019. Posted in Articles.

“Follow your passion, be prepared to work hard and sacrifice, and, above all, don’t let anyone limit your dreams”.

– Donovan Bailey, retired Jamaican-Canadian sprinter, who once held the world record for the 100 metres.

We know that great sponsors make major change initiatives exciting and successful experiences. If we could bottle that “great sponsor” juice, what do you think we’d find in the bottle? Chances are we’d find the ingredients that are present in this month’s case, the Nuts for Cheese project.

In this post, we’ll follow the path one woman took to develop her knowledge and skills and launch and guide a company that, in just three years, is now offering its high quality products through small and large retailers across Canada.

The Situation

In her early teens, Margaret Coons’ love for animals convinced her to adopt a vegan life style. That meant eliminating everything of animal origin from her daily life, including meat, milk, eggs, wool, leather, honey, etc. To her parents’ amazement, she proceeded to learn how to prepare plant-based foods that would complement what was available and prepared in the family kitchen and replace the meat and animal products that were consumed by the other members of the family.

Margaret continued her vegan lifestyle through her secondary and post-secondary school years, graduating with a degree in English Language and Literature from Western University in London, Ontario.

After graduation, she worked as a chef in a local vegan restaurant preparing plant-based foods. In the evenings, after work, she rented the restaurant’s kitchen to experiment and learn, developing her own recipes. They would often appear on the restaurant’s menu in subsequent days, giving Margaret valuable customer feedback on her creations.

In addition to the night time experimentation, Margaret completed Rouxbe’s Plant-Based Professional Certification, appeared on London daytime television with creative vegan cooking demonstrations and offered cooking lessons and classes at local fairs. She also provided private catering and helped other culinary establishments create vegan recipes. All this while working as a chef at the vegan restaurant. But her love and her specialty was creating cashew cheeses. She started her business on a small scale, offering her products at local farmers’ markets and contributing her wares at a local vegan food bank.

In 2016, the local vegan restaurant closed its doors. Margaret had a decision to make, and she made it – to go full time and full bore with her own company, designing, making and selling cashew based cheeses. And so she launched the Nuts for Cheese project.

The Goal

Margaret’s vison for Nuts for Cheese: To be the #1 selling, high quality, great tasting vegan cheese that people love.

The Project

Margaret’s initial challenge on hearing about the vegan restaurant’s closure was to find a new location and hire and train staff to help her get back up and running. She located and contracted for a small 1200 square foot space, hired four staff and was back producing her cashew based cheeses in short order, serving about 25 retailers and continuing to cover local farmers’ markets.

A year later the company landed Farm Boy as a client and moved to a larger production facility to serve the orders from a growing customer base. Two more moves were required in the following years as demand continued to grow. Nuts for Cheese now operates out of a newly acquired 11,000 square foot facility. The number of staff has also grown, currently standing at 23 and counting.

Margaret admits that she became an entrepreneur by accident. With little formal business training, she had to learn on the go. She has enjoyed the guidance of mentors along the way, including her current mentor who offers expertise on the grocery business, quality control and supply chain management. As the company is self-funded, she has had to master and aggressively manage cash flow, the supply chains, hiring and management of a growing workforce, putting an organization structure in place and, of course, the facilities to house her operations.

Margaret’s recipes for her cheeses are a reflection of the dedication and precision she brings to all aspects of the company’s operations. She starts with organic cashews which are soaked in filtered water for 24 hours to create the base cashew milk. The milk is then fermented for 24 to 36 hours using yeast cultures created in house. The fermented milk is then seasoned and aged to create the company’s unique offerings including Un-Brie-Lievable, Super Blue, Chipotle Chedder, Red Rind and Smokey Artichoke and Herb. The company also creates all its own seasonings using all organic sources.

Margaret’s passion for quality is reflected in her hiring practices. To date, she has interviewed every candidate and participated in every hiring decision. Her primary hiring criteria are personality match, values match, then skills. The use of only organic products and the creation and operation of rigorous quality control practices at each stage of the supply chain simply reinforces that quality ethic. The company has applied for and is currently waiting on formal organic certification for their products.

The Results

In the three years since its launch, Nuts for Cheese has tripled revenue every year. The number of staff has grown from four people to twenty-three. It has just moved into a new 11,000 square foot production facility to supply its products to retailers across Canada, including major grocery chains. And the firm was just named one of the top 14 employers in London. Not bad for an accidental entrepreneur!

How a Great Leader Succeeded

Margaret’s journey with Nuts for Cheese is a wonderful success story, but it’s also a wonderful roadmap for managing any kind of change. The values and tenacity she brings to her job as CEO are the same qualities and attributes that make great sponsors, successful projects and wonderful experiences in any field. That includes:
1. Knowledge – Margaret built her vegan knowledge from her mid-teens on, studying, experimenting, sharing and soliciting feedback iteratively and incrementally. From her early ventures into a vegan diet, to the restaurant’s kitchen, to her after hours experimentation and creation, to her formal education, Margaret acquired the knowledge to succeed in her Nuts for Cheese adventure and openly shared that wisdom.
2. Commitment and passion – Take a look at Margaret’s goals for her company. #1 seller. High quality. Great tasting. People love it. Take a look at the recipe. All organic with quality control processes to ensure that’s the case. Seasonings and yeast cultures created in house. Take a look at who and how she hires. Personality, values, then skills. Involvement in every interview and hiring decision. Add Margaret’s regular 80 hour weeks to that mix and it’s evident that passion and commitment are drivers of the company’s success.
3. Collaboration – Perhaps more than anything, collaboration characterizes Margaret and her company. From her early years with her family, to the restaurant experience, to her engagement and work with mentors, to her relationship with her staff, customers and communities, collaboration has been the hallmark of her approach to life and business. That’s how the name for the company was developed – brainstorming with friends and colleagues.
4. Sharing core values – Margaret hires people who share the core values she wants for the company. That reinforces and builds a collegiality based on customers, quality and success. The company’s selection as a top place to work is evidence of the strength of that sharing.
5. Lessons learned – Without a business background, Margaret and her staff have acquired and shared the operational, supply chain, quality control, marketing, distribution and product development skills and insights needed to grow the company and provide their customers across Canada with tasty, quality products.

In his article The Speed Trap – When Taking Your Time (Really) Matters, Tom Peters states: “An organization is nothing more and nothing less than people (our folks) serving people (our customers and communities).” It is evident Margaret got that right. She “owns” her Nuts for Cheese project lock, stock and barrel. It’s also apparent that her staff shares her ownership. That’s the force multiplier. The whole is significantly greater than the sum of the parts. If you are a project or change manager, imagine what your projects would be like if your sponsors, key stakeholders and project staff exhibited the characteristics described above.

So here’s a suggestion: use these points to evaluate your sponsors, key stakeholders and project staff. If there are gaps and deficiencies, include activities in your project plans to build collective capabilities and close the gaps. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and the Decision Framework (including key stakeholder assessments) right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation on this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your experiences.

Why your Team Needs Business Analysts

Written by Yasmin Ledward on March 4, 2019. Posted in Articles.

Business analysts are not new to the tech industry, but some may wonder what skills and value they bring to a team.

Some individuals may wonder what a business analyst is, so let’s start by clearing that up. The role of a business analyst can be defined as the bridge of communication between the IT staff working on a project and the business stakeholders.
Their main responsibility is organising discussions between the business users to understand their business needs for change and then to communicate these needs to the IT staff, so they can design and build a system that is what the business user requires and up to the business stakeholders’ expectations. Along with being the facilitator, a business analyst is responsible for documenting requirements, user specifications, cases, test plans, implementing test plans and supporting the project manager, customer and development team.

Reasons why they’re needed

A business analyst can bring a maximum efficiency to a project team and this can sometimes be overlooked. While the development team outlines the technical solutions, the business analyst provides information, answers questions, eliminates obstacles and ensures that the technical solution is developing forwards to meet the stakeholder’s expectations. A business analyst can bring a lot of value to all departments that are working on a project as well as the customer. However, some may ask what these values are, so below are some reasons as to why your team needs business analysts.

Reducing project cost

Business analysts are needed within a team as they can help to reduce project costs. Although it may seem like you are spending more money as you will need to hire and pay a business analyst, in the long run, they can help to reduce the cost of the overall project that they are working on. One way they can help reduce the cost of the project is by reducing re work that takes place. For example, when your developers start coding for a business user, it may not be exactly what they wanted and may have to be looked over and re coded. Something that starts so simple can then become so complex after stakeholders’ requests come in and you will find yourself re working the elements you first started the project with. Therefore, having a business analyst can help stop this re work as they will know what the business user demands are and how to translate this to the developers, so they get it right. This will result in stopping steps within the project being delayed which can cost any company money.
Secondly, it can take some time for businesses to figure out what it is they want from a project and this can be costly. If requirements meetings were to take place regularly without some form of solution being made in each one, then this can cost the company a lot of money as you will be holding up meeting rooms and stakeholders time. Therefore, this is where a business analyst would be valued as part of there role is to come up with solutions, create a logical decision-making process, remind others that they may have made that suggestion before and fill in those communication gaps between the different departments working on the project. Business analysts would prevent multiple meeting from happening between stakeholders which would save the business money.

Increasing potential return

Increasing the value of a project will help to increase potential return for a business as they are becoming more efficient. Having the development team divide a list of say 100 things that need to be done and grouping them by the area of the system can cause issues later in the project as they may not have been grouped by value. By doing this you may be grouping tasks at the top of the list which aren’t that important. By not having any focus on prioritisation can cause your project to lose value. One of the main skills that a company would want in a business analyst is prioritisation. Therefore, by having a business analyst in your team to deal with all the requirements needed for a project, they would help to add value to the project and provide potential return.

Miscommunication

Many developers are grateful when they have an experience business analyst working on a project with them as all they want to do is code. Having developers interacting with business users and lengthy requirement meetings isn’t productive. Developers tend to want to design a solution before knowing the full scope of requirements that are needed for a project and business users sometimes do not like this. This normally causes discomfort and confusion for the business users and can have a negative impact on the overall project. However, the business analyst understands the detail the developers need to go into to bridge the gap between business requirements and technical requirements. Although developers are more than capable of working with business users, it can cause project delays and re work due to the miscommunication. Therefore, business analysts will bring value to the team as they understand technical requirements as well as business requirements and can interact with the business users as well as the developers to ensure that there aren’t any project delays.