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 John Parker | Feb 25, 2013 | Testing, Uncategorized |
There are numerous types of system testing that can be done as part of the system testing and deliver process. Below is a list of test types identified by Guru 99. This is probably the most comprehensive set of tests that I have ever seen, and it makes a great guide when planning your quality assurance activities. Naturally, the team selects that group of tests that make the most sense in the circumstances. Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. This testing process is usually performed by customer representatives. Accessibility Testing: Type of testing which determines the usability of a product to the people having disabilities (deaf, blind, mentally disabled, etc.). The evaluation process should be conducted by persons with disabilities. Active Testing: Type of testing consisting in introducing test data and analyzing the execution results. This testing process is usually conducted by the testing teams. Agile Testing: A software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. This type of testing is usually performed by QA teams. Age Testing: Type of testing which evaluates a system’s ability to perform in the future. The evaluation process is conducted by testing teams. Ad-hoc Testing: Testing performed without planning and documentation – the tester tries to ‘break’ the system by randomly trying the system’s functionality. This testing process is performed by testing teams. Alpha Testing: Type of testing a software product or system conducted...
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...
