For some time now, since a conference I ran in July on Agile and New Forms of Organization, I have been trying to get clear in my mind what the difference is between an “agile team” and a “cross-functional team”. Also, I recently participated in a cross-functional team looking at ways to improve the performance of corporate functions.
Cross-functional teams have been a feature of organisation since the 1960s, when Boeing first developed a new aeroplane using a multi-functional approach. This successful experience was documented by Jay Galbraith, who called it a “matrix structure”. It was the first documented use of matrix organisation ideas: in Boeing’s case a function/project matrix. At various points in time since then, cross-functional teams have been much written about and much used.
So what is new/different about Agile compared to cross-functional teams? Here is my list
Content marketing is all about producing quality content and making it reach your target audience. It’s a sort of strategically planned content development which is supposed to lead to profitable actions by the customers. The traditional “heads-down” content production is how things were done before Agile. Now, Agile is bringing in some serious changes.
When we’re talking about Agile marketing, we’re talking about innovation. It represents a non-traditional approach to work organization and structure, which makes room for positive changes and better workflow. In order for you to understand how going Agile works in content marketing, we’ve prepared useful facts and explanations. Let’s take a look.
The Development of Agile
The Product Backlog is the heart of defining any Agile solution. The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment. This is the second of two articles that provide you with techniques for maximizing the value of the features in your Product Backlog. The first article, Maximizing the Value of Your Product Backlog (Part One): Gathering the full scope of req
The Product Backlog is the heart of defining any Agile solution. The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment. The challenge is that most Product Backlogs are based on input from selected stakeholders, rarely representing the full scope of requirements - and constraints - that need to be considered before priorities and business value can be accurately identified.
This is the first of two articles that provide you with techniques for maximizing the value of the requirements in your Product Backlog. This article focuses on ensuring that you have considered the full scope of potential sources for identifying what the solution needs to deliver - and equally what it should notbe delivering.
We all know how to plan. From waterfall, we know how to over plan. But how much planning is necessary if you are using an agile approach? Here’s an idea…try starting the first piece of a project before you have the full plan. Radical thought? Did your heart skip a beat? Here’s why this experiment might change your attitude about planning.
This is the second in a series of articles that will give you strategies for aligning your Agile work to your organizational structures. The first article focused on delivering Agile projects within existing Project, Process and Quality Management frameworks. In this article, the focus is on delivering Agile projects within the existing corporate reporting structures of your organization.
Agile approaches provide a number of mechanisms for tracking progress, including formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards and product backlogs), and ongoing communication with stakeholders.
The ideal Agile reporting environment would leverage these tools without asking staff to do extra (often redundant) work to meet corporate reporting requirements. Specifically, this would involve using:
Agile is an iterative form of software development. Through its rituals and ceremonies, it provides a quicker way to deliver value to the actual customer of the software. Through its focus on prioritization, agile insists that the work most important to the customer be completed first. Through its dedication to team empowerment, agile pushes the “how” to the team level where the team takes ownership of delivery and quality. As agile has proven its value in the software engineering field, it also has many concepts that can prove beneficial to other IT areas. Listed below are some of those concepts and examples of how they might be implemented.