by Jenny Boronyak | Sep 10, 2014 | Agile, Uncategorized |
When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development. But there’s so much more to being agile than delivering software products iteratively and incrementally. If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands. On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently. In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business: Enterprise Agile Delivery The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs. Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements: Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using...
by George Casey | Oct 22, 2013 | Business Analysis, Collaboration, Uncategorized |
There is no “I” in team, and research shows there hasn’t been one for decades. Teamwork and the ability to succeed in a team environment – for the betterment of the team – are not new concepts. The skillset continues to be called on by managers and business leaders, and through the years, it has become a fundamental value of employees across all industries. Recognizing how important teamwork is to collaboration and communication, especially in requirements development, we revisit John Maxwell’s resource from 2006, the 17 Essential Qualities of a Team Player. In it, Maxwell asserts that teams win when they have good players, and on collaborative teams, each member has a talent that strengthens the whole team. Here, we revisit those 17 characteristics, recognizing that their importance never goes out of style. 1. Adaptable. Good team members are able to work with a variety of groups, from stakeholders to developers. They are flexible, open to different mindsets, and able to transfer their knowledge to new groups and endeavors. 2. Collaborative. Good team members see others as co-workers, not as competitors. They focus on the group and celebrate collective victories. 3. Committed. Teams are successful when they have members who are dedicated and believe in the value of their work. Good team members increase their level of commitment when they face a challenging task: The more difficult the problem, the less likely they are to give up. 4. Communicative. Communication is essential to team-building. Good team members communicate candidly and directly. When a problem arises, they resolve it promptly. 5. Competent. Good team members make a commitment to excellent...
by George Casey | Jun 10, 2013 | Project Management, Uncategorized |
While terms like “Geek Squad” and phrases like “The geeks shall inherit the earth” are humorous, it’s common knowledge that “geeks” – high-tech specialized knowledge workers – provide tremendous value in technology and business. Because they’re so important, it’s imperative to understand them, manage them, and lead them effectively. No one knows that more than Paul Glen, author of Leading Geeks. In this book, Glen asserts that geeks are essential for continued innovation, either to generate new ideas or to implement the ideas of others. They are knowledge workers who specialize in creating, maintaining, or supporting high technology. While they are often found in IT, they also have roles in accounting, finance, marketing, sales, or customer service. We need them – but what makes them tick? Geeks are, according to Glen: Reason-based – Geeks value logic and rational input Focused on problem solving – “In every situation,” Glen says, “They seek out the problem and try to solve it.” Childlike – Geeks are intelligent and often very successful early on, in years when they might have been developing social skills or self awareness. Based on this, they are often childlike and still new at adjusting to social situations and intuitively knowing how to act. Curious puzzle solvers – Geeks love intellectual activities that make use of their knowledge, creativity, and logic. Geeks can also be poor communicators, and be prone to interpersonal conflicts. They can also be resistant to following typical organizational policies and structures, believing they should have exemptions based on their specialized work, technical skills, creativity, and intelligence. How to lead them Glen says effective management involves...
by Karl Wiegers | Sep 19, 2012 | Business Analysis, Uncategorized |
Some agile software development approaches have as a central tenet the premise that every project needs a full-time, on-site customer who sits with the developers. The rationale is sound. Only knowledgeable and empowered customer representatives can answer questions and flesh out high-level requirements in appropriate detail. Failing to get timely answers or clarification holds up development and forces the developers to make their best guess. The right customers also can provide quick feedback on proposed user interface displays, clarify points of confusion, and resolve conflicting requirements and priorities. I fully endorse the premise of intimate, ongoing engagement of appropriate customer representatives on software projects, as well as the need to get input from a wide variety of other stakeholders. My concern about the phrase on-site customer is simply that it is singular. It suggests that a single individual is available who has sufficient knowledge, expertise, and authority to make requirements decisions on behalf of the entire user community. Even if you could find one such highly qualified representative, other demands likely will compete for his time unless he and his management make participating in the project a priority. In this article, adapted from my book More about Software Requirements (Microsoft Press, 2006) I describe a more effective approach to finding the literal voice of the customer and engaging customers on a project. User Classes and Product Champions In reality, most products have multiple—often many—distinct user classes, groups of users who have largely different needs. Certain groups—the favored user classes—will be more important than others to the business success of the project. Sometimes user classes aren’t even people: they’re other...
by John Parker | Sep 18, 2012 | Agile, Business Analysis, Product Development, Uncategorized |
There are three fundamental roles in Scrum: Product Owner, ScrumMaster, and Team. This article discusses the Product Owner in how in many cases a Business Analyst is the best person to serve this role. Product Owner is the most demanding of the Scrum roles. The Product Owner creates a vision of what needs to be built and conveys that vision to the Team. Effectively communicating this vision is key for beginning any agile software development project. In Scrum, the Product Owner is the primary person responsible for ensuring that the solution delivers business value. The Product Owner leads the development effort by conveying his or her vision to the Team, creating requirements (user stories) in the backlog, and prioritizing user stories based on business value. The Product Owner must work closely with stakeholders and the Team to make sure their interests are included in the release. The Product Owner works closely with the Team to negotiate work assignments, resolve issues, and ensure that the agreed upon work is completed by the end of the iteration. The Product Owner must be available to the Team during the sprint to answer questions and deliver direction. This combination of authority and availability to the Development Team makes it difficult for the Scrum Product Owner not to micro-manage. However, Scrum places significant value on self-organization and, as a result, the Product Owner must respect the Team’s ability to create its own plan of action. This means that a Product Owner is forbidden from assigning the Team more work in the middle of the sprint. Even if requirements change or some business dynamic arises...
