Sometimes we need something that just works. Not everyone in development can be a master videographer, yet there has to be a way to boost our marketing and training needs. That’s where videos come into play. At Axosoft, we have been using Camtasia 2 recently and would like to share our experience with a review.
Camtasia 2 (as described on Techsmith) is a screen recording and video editing tool. It differs from other solutions like iMovie or Adobe’s Premiere in that it focuses on providing easy screen capture without needing to juggle several media files or get a PhD in videography. While we have enjoyed using it, there are some snags we’ll talk about towards the end.
First off, I have to say that screen capture is pretty easy with Camtasia 2. Before, I used Snapz Pro X to first capture my screen which would then be exported as a .mov file to then be imported into iMovie and then edited. It was a process. With Camtasia however, your recording is immediately ready for editing once you finish capturing. You can set the screen size, use your own mic, and restart recordings.
The tool keeps all your recordings and other media in one place. You drag and drop the media onto the tracks to begin editing from there. Camtasia 2′s learning curve is not that steep, which makes it approachable for folks (like myself) making video series for the first time. Once I learned how to cut, zoom, and transition in the tool, I was able to produce a great rough cut overlaid with music.
We got really excited about the effects in Camtasia 2. The annotations, transitions, and animations are pretty easy to use (just click and drag) and they punch up the quality of the content a few notches. Initially, we were sold on the ability to track your mouse cursor. Surprisingly however, I found myself using annotations more than the mouse tracking. You’re given many options in styles and customization, and you can even add transitions to the annotations.
Snags: Nothing is perfect, which is great news for developers (yay, job security). Something I did appreciate about iMovie is its ability to freeze frames. It’s easy. You just scrub over to the frame you desire, click freeze frame, and adjust the duration from there. With Camtasia 2, the freeze frame equivalent is “Extend Frame to Playhead” which works…sort of. It does get the job done but first you have to cut, select, extend, and then adjust again (and it took some time to discover). Perhaps I’m being nit-picky, though the feature could be more elegant.
Also, if you ever move the file locations, Camtasia 2 will lose files until you tell it where you put them. An understandable side-effect that is mostly mitigated if you keep your files in one place initially. If you’re about to get going with Camtasia 2, just be mindful of this in your workflow.
If screen capture is a huge part of your video editing, then Camtasia 2 will do the trick beautifully. If you’re a hardcore videographer, then you’re probably looking for something more robust but otherwise this is a great find.
Hey Folks… I’ve never posted anything like this before, but I wanted to let you guys know we are growing and looking for a few top-notch coaches to hire over the next several months. If you are interested, or know anyone that is, please give us a shout.
That said, let me give you an idea of what we are looking for in our ideal agile coach.
1. Our coaches come from a variety of backgrounds so there isn’t really one profile that fits for us. We have folks that have been senior executives in large companies as well as executives in startups. We have people that have started and run their own businesses. We have people that come from a more traditional training and coaching background and we have people with a more traditional management consulting background. The people that tend to work out best for us bring a passion for agile, pragmatism about what agile looks like during a transformation, and a sincere passion for helping people and organizations get better at what they do.
2. As you might expect, you need to be an expert in agile. You should be steeped in the literature and extremely knowledgeable about the entire family of methods. You should be conversant in Scrum and XP as well as Kanban and SAFe. You should know about Crystal, DSDM, FDD, and Lean and where they fit into the body of knowledge. You should have a background applying a wide variety of agile methods in complex environments. You should have the conviction to stand firm on principles but a willingness blend and bend approaches as necessary to help our clients be successful.
3. We need you to be confident and self-assured yet humble with a willingness to learn. While we are not a training company, it would help if you were a gifted trainer full of anecdotes and stories about agile teams you’ve worked with and transformations you’ve lead. You need to be able to hold a room for several days and connect with all levels of an organization. You should be equally comfortable working with a room full of executives as you are with a room full of developers. You’ll often need the ability to speak developer to the business people and business to the developer people. A broad, inclusive perspective is essential.
4.You’ll need to have a strong degree of emotional and social intelligence and have the ability to read a room and adapt your approach to meet the unique needs of the people you are working with. You should have excellent problem solving skills and the cognitive resources to develop customized solutions on the fly, brainstorming ideas with senior leaders in unfamiliar and unique problem domains. You need to be able to work and collaborate with an expert team of coaches, every one of them with strong opinions and unique points of view, and craft solutions that work in the best interests of our clients.
While we strive to find local work for our coaches, if you are not in Atlanta, Washington DC, Orlando, Denver, New York, New Jersey, Los Angeles or San Francisco… you should expect to travel nearly 100%. Local work isn’t impossible to find in other areas, I just wouldn’t count on it. These are the areas where we currently have the most traction or an established client base. That said, even if you are working in your home town, some travel is pretty much inevitable.
You should know that a big part of what we do is probably less coaching and more management consulting. If you are familiar with our approach, you’ll know that we take a pretty hard stance that we have to define a structure, governance, and metrics model as precursor to leading a transformation. We are pretty prescriptive with many organizations, especially early in the process, about how we are going to implement agile. In the complex organizations where we work, playing soft will get us fired. We walk in with a point of view and a plan and a strategy for helping get the transformation started.
In return, we offer a pretty unique environment to work and a very interesting compensation plan.
We are totally distributed but operate in a series of small independent teams we call tribes. Each tribe has all the roles necessary to deliver an account. While you might be flying solo on any particular engagement, you have the support of a complete cross-functional team to share the load. Within the LeadingAgile transformation framework, your tribe has a ton of autonomy to do anything necessary to deliver for the client… you can even ditch the framework if you have to. If we find our approach stops working for us or our clients, we’ll change it. All policy and process is owned by the team we make changes using an open source/committer model.
We are committed to full transparency when it comes to salary, margin, and operating costs, and such within our organization.
We are in the process of moving all our coaches to the same base salary. Each coach has the opportunity to earn an extra 20% of their salary if the company meets certain delivery targets and its a whole team incentive. We are working on a model that can create significant upside for our coaches for certain kinds of sales and marketing activities and we are building a stock option and stock purchase program so everyone has a stake. On occasion we’ve been able to craft unique compensation plans to accommodate special situations where a coach has an established pipeline and/or a proven track record of business development success.
We are definitely a work-in-process and quite often operating way above our WIP limits. If you’re interested in driving meaningful change in large complex organizations, and you want to work for a unique, fast-paced, and innovative early stage growth company… hit us up on the Contact Us page, we’d love to talk. Please make sure to have a resume handy as well as links to anything you’ve posted recently that will give us an idea of what you’re passionate about and how you think.
The post LeadingAgile is Hiring Agile Coaches and Consultants appeared first on LeadingAgile.
Retrospectives empower the team to control their own destiny.
@lgoncalves1979 and @BenLinders
- Agile Retrospectives slides – by Esther Derby http://t.co/fSvtIQQb35
- Scaling Retrospectives « by LeadingAgile http://t.co/M8uTVk8bJt
- Agile Game Development: Productivity is a function of engagement, skill and accountability http://t.co/fczgcrvkgG
- The Power of Retrospection | Mob Programming http://t.co/JyjlkgsekS
- Valuable Agile Retrospectives: How to Do Them? | by Ben Linders http://t.co/6vviztFFcr
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Question: What do you get when you mix …
- 7 social-impact organizations tackling tough problems around the world
- 1 Google Glass inventor teaching rapid prototyping to help people and the planet
- 60+ people acting as “citizen engineers” for the day
- 1 incredible partner orchestrating the mashup
Answer: A fast-paced, collaborative, learning-by-doing experience where everyone leaves inspired and ready to use their new skills to bring meaningful change into their workplaces and communities.
Rally’s corporate social responsibility initiative, Rally For Impact, aims to tap citizen engineers -- people and organizations using technology -- to benefit communities worldwide through environmentally, economically, and socially responsible solutions. Reflecting on the event, Ryan Martens, Rally Software founder and CTO, said,
“The scrimmage is the best event we have done to instantiate our social mission of creating and mobilizing citizen engineers. We did this with our employees and customers coming together to help amazing social enterprises that are exemplars of citizen engineers in the world. For me, the scrimmage was a dream come true.”
Ryan Martens, Rally’s founder and CTO, teaches, learns, and collaborates with passion and purpose.
More than 60 scrimmage participants, including Rally customers attending our annual RallyON conference, worked alongside a handful of employees and learned about rapid prototyping directly from a master -- Tom Chi, former user experience lead at Google X. Rapid prototyping is a method used to accelerate the innovation process for devices like Google Glass and it’s designed to save time and money by quickly collecting and integrating user feedback around ideas for new business models, marketing messages, products, and services.
Tom Chi, a master in rapid prototyping, shared insights with all scrimmage participants during the midday retrospective.
“My team worked with FarmBot leaders to create sustainable, inexpensive means to grow your own food via a farming robot. Our interactions with Tom Chi as our ‘user’ for many of our developing ideas helped us uncover amazing insights that I don't think we would have gained any other way.” -- Steve Rhoads, Rally Software Agile Coach
With guidance from our talented partner and fellow Certified B Corp, ReWork, we hand-picked nonprofit and social enterprise organizations with citizen engineer mindsets that are tackling tough social problems around the world. Each organization presented a compelling challenge or a new idea it was itching to test:
- Engineers Without Borders
- Wello Water
- DayOne Response
- International Development Enterprises (iDE)
- U.S. Green Building Council
Tim Prewitt, CEO of iDE, explained his organization’s challenge to fellow team members.
“Engineers Without Borders really benefited from the Rally Scrimmage. Not only do we have a way of solving the challenge we presented to our team, but we look forward to using rapid prototyping as the organization continues to grow and enhance its operations.” -- Cathy Leslie, Executive Director, EWB-USA
Guided by expert facilitators, we joined forces in small teams and collaborated for four hours, quickly iterating on our organization’s challenge by using our newly acquired rapid-prototyping techniques to gather feedback from user testers who were available on demand.
That’s me in my role as a user tester, giving feedback on an idea.
“For me this Rally scrimmage event … the 'hands-on-ness' was a turbo-charge. This was real-world concepts and ideas, and these charity organizations are really things that we care about. So it was something you could really sink your teeth into.” -- Scott Heffield, Veracity Solutions (Rally customer)
After more than five hours together, the people in the room were still abuzz with energy as we gathered in a circle to share learnings and insights with team members, facilitators, and leaders from the social impact organizations.
Wrapping up a great day of work and play with a closing circle.
More images tell the whole story! Check out the Rally For Impact Scrimmage photo album on Facebook.Geri Mitchell-Brown
Today I want to tell more about our *relationship* with bugs, fixes and smaller work. The way a software development company prioritizes their backlog depends on a number of things, and I will give an example of how we’ve explored various solutions to address the changing priorities. There’s never one single “How to prioritize backlog” recipe, and I want to caution everyone against blindly following a practice that worked for someone else. In each particular case, everything depends on the current context in which company finds itself at any given moment: how many developers are there in the company, how many customers, which strategic priorities does a company have. In short, smart pragmatism is the only universal tool that would help tackle a specific business challenge, not a ready-made “how to”.The Product Backlog: New Things and Fixes
Speaking from our experience, product backlog usually includes the following 2 groups of work items:
-new features (or some fundamental re-work for the existing features) which require at least 3-4 months work for 5-6 developers and QAs
-fixes and reworks to existing product features (based on feedback from leads/customers, and from the team)
In Targetprocess’ 10 year history there was a time when one product owner prioritized backlog both for the new features and for fixes and reworks. When we were a relatively young company, the product owner’s main focus was on the new features, and the smaller fixes and re-works for existing functionality used to be tucked under the rug. The limit of items allowed in the Planned state on our Kanban board was 20, and the clean-ups were triggered by the following logic: “Hey, we’ve got a lot more than 20 items in the Planned state! Hmm… we actually got 50 bugs there! All of them are small bug fixes and enhancements, so let’s just pull them from the backlog and fix, whatever whoever wants”. So, developers would pull the bugs, fix them and a new build would be out. This practice worked well, but there was one link missing.The Imbalance in Controlling a Backlog
With time, we’ve had more customers and more functionality in the product, which meant more areas where fixes and re-works begged to be done. Some people in the company who interface with customers and absorb their requests (or complaints) started feeling the pressure, and they wanted to do the fixes that a product owner wouldn’t consider that important. It’s not only about the pressure, of course. Customers’ needs must be taken into account, because they want the product to work better for them. And product owner wouldn’t get a clear idea of how crucial each small request was, from where he was sitting. The disconnect between “request points of entry” and “control over backlog” became too obvious at one point. We still had one product owner controlling the backlog, and he prioritized it as per his vision. He did have an idea of which things are most requested by customers, of course, but the new functionality would still get a higher priority. The ultimate clean-up days, where developers would pick and fix bugs at random, without knowing what customers want, were not of help any more.
We then understood that we needed a new approach to handle those smaller bugs and reworks. The backlog now had to be prioritized not only by what product owner had in mind, for the new features, but based on the priorities that were defined essentially by our customers and leads, in their exchanges with the product specialists and with our support team. Besides, the new functionality also needed some re-works, and we had split opinions on what’s more important and what should be done next. Something had to be changed in terms of backlog ownership. A person (or the people) who would control the backlog needed to be up-to-date with the priorities as identified by multiple contributors: product specialists, support team and product owner (or, later, the product board).Who Will Do the Bug Fixes and Smaller Re-work? The Emergency Team
On the other hand, we realized that we need a dedicated task force for those re-works, not just clean-up days. That’s when we formed an Emergency Team. At first we used the rotation principle for it. Each of our Feature Teams would act as an emergency team for 2 weeks. Then, at one point, it became clear that a simple rotation is not a good idea. It takes time for teams to fully get settled in the context of their work, and as the team is formed it idles at first, just like an engine, and then gains speed. The rotation assumed that exactly by that time the team had to be switched. It appeared that mere time-boxed rotation ignored this important nuance, so we decided to have a permanent emergency team. The emergency team, in our understanding, was supposed to work as a point of entry for new developers, so they could know the codebase better. However, we didn’t get into account that newcomers needed to check on some things with the “old” developers. That hindered the work, and we eventually switched back to ~1 month rotation principle. One month seems to be a sensible time for the emergency team to gain and sustain the optimal productivity momentum.
The backlog for this Emergency Team was at first prioritized by product owners who would rotate weekly. One week that would be one of product specialists, then someone from a support team, then a product owner or one of UX designers. Then we realized that one rotating product owner is not working well. This person is not able to keep in mind all the priorities. Now the backlog is formed from 3 queues: Support, Product Specialists and Product Owner AND this work is prioritized at a meeting with emergency team lead developer, product owner, product specialists and support. Roughly, each of the sources has 25% share in the Emergency Team backlog. Currently this team is doing small things to improve the product on-boarding experience for potential customers, and they did the print cards functionality in the recent 3.2.4 release. For comparison, features teams are working on large features such as timelines or lists.
I’m jotting down a few notes on Scaling Agile software development as Bucharest Agile group invited me to talk about doing this. I have already warned them that I am very skeptical about attempts to apply agile practices on large endeavours. While preparing for our conversation, I thought it might be helpful for me to blog about the reasons why I’m not a fan of Scaling Agile as this may make our conversation easier to follow and help the group to come up with some questions.
When we apply Agile principles, we strip away process so that software developers can work more collaboratively with business people to identify what is the most valuable thing for them to deliver next. We focus on building working software and releasing as early as we can to help us figure out what to build based on feedback from users. Working this way is much harder when a lot of people are involved!
A bunch of things break down as you scale up. The biggest one is not being able to maintain interpersonal relationships through which rich information flows, these are replaced with weaker lossy forms of communication and misunderstandings about what is the right thing to build next follow.
Typical things that become difficult at scale are access to business people and infrastructure controlled by others outside immediate team. Meetings get long and tedious, we start sending a representative from each team, which introduces more secondhand information, emails and documentation.
When a project is big and is being changed by many hands it becomes much harder to understand the whole, we start to introduce hierarchy with a select few looking at the bigger picture and paying attention to separating concerns to allow different teams to work in parallel. As a result, choice is removed from the team and it can feel in teams that edicts come down from on high through a series of chutes and screens that mask the reasoning behind them.
Often the initial attraction of Agile approaches to a business is to reduce delivery timescales and enable developers to work faster with a lightweight approach. Working in small teams allows individuals to feel more engaged because they have some influence on how things are built. When a lot of people are working in parallel coordination becomes harder. Ideally we need skilled people who have enough experience to work independently without the guide-rails of process.
Yes, I have seen plenty of organisations with large systems being maintained, expanded and extended by multiple teams. When each team has to interface to many others decisions take longer to make. Where a large number of people are working on a complex thing, it takes a lot of effort to keep up with what’s happening other areas and most reduce their focus to the work at hand. Once they reduce their focus and interfaces between teams become walls to hide behind. When myopia is easier then teams tend to make local suboptimal changes rather than considering the whole.
A large body people working on a large body of code often feels crazily chaotic or oppressively bureaucratic to work within. In these conditions developer motivation is often dimmed, people leave taking away valuable knowledge of how the system evolved and why things are. New people who need to learn how things work join and struggle to make sense of it all, the situation gets worse.
There are a few agile practices that can help in scaled up situations - such as having reliable automated builds, decent test coverage and teamwork but these are also painful to maintain with a lot of people involved. I’ve seen many large organisations attempt to apply Agile at scale. It’s hard and although it can bring more humanity to work in-the-small, I’m not sure there is much evidence that it is actually better than traditional ways of organising the work.
I appreciate that there are large systems out in the world that need to be supported and evolved to better meet user and business needs. I remain unconvinced that throwing a lot of people at the problem makes things any faster. I believe deadlines driving this behaviour are defined without realising the impact on the maintainability and quality of existing software. Code is an asset and so is the knowledge that software developers carry - businesses can run into costly mistakes if they ignore their value.
Attempting to scale to go faster is driven business greed and ambition - not a bad thing in the commercial world but it’s like seeing a someone blindfold attempting to run along a cliff edge while juggling priceless antique glass vases. Mistakes at scale are costly!
When it seems that scaling up is the only way to go, challenge yourself to think of a smaller simpler thing to build sooner that gives faster feedback. Try to limit your total Work-In-Progess by reducing the amount of development being done in parallel across the organisation. When a smaller group of people is involved in development, choices about which way to go next can be made more quickly and there's less waiting around. Ultimately, this goes back to Agile Manifesto values - focus on better interactions betweem individuals to produce valuable software sooner -- not on a process to enable lumbering projects at scale.
Assessments come in all forms, and there are many reasons why we do them. In the end, we want to know something about the ability of someone or something.
When working with a team or organization, an assessment can be introduced as a tool to assist in guiding an agile transformation and team improvement. For me as a coach, it’s an invaluable mechanism to communicate the transformation strategy and to measure progress.
I love the simple approach taken in Elizabeth Hendrickson’s, “Back-of-the-Napkin Agile Assessment Checklist,” but sometimes we need something more extensive in an enterprise transformation setting. At least until our organization or team has reached a more mature state of agility.
Over a series of posts, I’ll cover the Why, What, When, and How of assessments and wrap it up with a post or two about how the data can be used once it has been collected. In this post, I’m going to talk about the Why and What of assessments.
You will see at times that I refer to ‘assessment’ and, at other times, ‘self-assessment.’ While the two are not completely interchangeable, I usually make the slight distinction that an assessment is scored by someone evaluating another group. Even for the self-assessment though, ideally there is an experienced guide facilitating the process until a team is more familiar with agile practices and capabilities.
So why do an assessment anyway?
Let’s consider some of the reasons you might be doing an assessment with a team or an organization:
- Baseline the current level agile adoption. Eventually, you may think about measuring progress, but take the time to baseline your abilities right from the start.
- See how you’re tracking against your adoption or transformation goals. Help sustain and grow your support.
- Determine if you’re ready to move to the next level of practice or adoption. Be honest, critical and brave!
- Recognize what has been mastered and what you are able to do with the new skill or capability. Change is tough so remember to celebrate your wins.
- Identify the next things you’re going to work on. Help the team narrow or target their focus.
- Set the context for organizational change. Use the assessment instrument as a change management tool.
- Make or support the case for needed coaching or training. Outside help can propel your progress.
Sometimes an assessment or self-assessment may be for other reasons, such as creating a transformation roadmap or showing progress in order to secure continued funding. Even in these cases, I prefer to involve the team as much as possible so they can learn from the exercise and use the information derived from the assessment to target and make improvements.
What sorts of things do we look at in an assessment?
A team can be measured by improvement of a few practices or against more extensive measures that are part of a competency framework.
A competency framework conceivably will focus on things we do, like Stand-ups, Iteration Planning or Retrospectives. It could also focus on capabilities such as Decomposing Features or Define Clear Acceptance Criteria. Or even against concepts like Whole Team or Open Workspace. Using a known competency framework can be useful to bring a level of consistent understanding across teams in the organization. It also facilitates alignment of good metrics as you plan and measure the finer nuance of implementing a particular practice or capability.
The following section is a sample of assessment practices and capabilities along with a description for each.
Competency Practice or Capability Description
Identify Epics and FeaturesProvide a clear definition of the product goals on the roadmap as feature and epic level deliverables valuable to the business. Produce visual specification around the Epic and Feature: personas, a feature flow chart, use case diagram, etc.
Define Clear Acceptance Criteria
Define what it takes for a product feature to be ready for use and the definition of done is clearly internalized by the team.
Team is working from a single prioritized backlog, WIP is limited.
Architecture aligned and actively involved in release planning. Architecture is actively working with teams to groom solutions
Collective Code Ownership
Developer can make code changes anywhere they need; developer can change code, fix bugs, refactor as necessary; few silos of knowledge.
Continuous IntegrationAutomated builds occur at every check in, tests pass locally before check in, immediate feedback when new code breaks the build. Plan & Coordinate
Eliminate & Manage RiskCoordinate work across teams to limit impact of both internal and external risks to the team.
Plan & Groom the BacklogHave enough work groomed ahead of the team so the team can do the work. Organization Enablement
Empowered TeamsPeople take ownership for their commitments and outcomes, within a defined set of organizational constraints.
Develop Practice CompetenciesDo people have time to develop their craft? And do they put effort into it? Help the teams make appropriate decisions when applying the practices in their daily work. Communication
Whole TeamTeam sits together, co-location of business/product owner, team is asset/product based, team has identity not based on project, product or department.
Daily Stand-UpOccurs daily at same time, lasts 15 minutes or less, roadblocks surface and are visible, team selects stand-up time.
The Roll Up Competency, or category, shown in the first column will bring perspective to your competency framework when you describe it to others and when you process the results. I’ll show a few analysis/reporting samples in my follow on post ‘Using the Data’.
In my next post, I’ll talk about Rating Scales and Frequency, followed by Assessment Delivery Methods and finally, Using the Data you’ve collected, including use of the roll up categories.
School's out for summer, as they say, and if you listen closely you can hear the sounds of worldwide slacking-off. Even as you read this, your brain cells are probably withering in air-conditioned intertia.
Well, summer school is no longer just for cool kids and misfits.
In fact summer is an excellent time to brush up on rusty skills and acquire some new ones. Lucky for you, Agile University is in high gear, with a summer schedule of professional training courses that offers something for everyone, in locations around the globe. Here's a little pop quiz to get you going.True or false: the number of Scrum-related jobs has doubled in the last four years.
It's true! According to Indeed.com, job postings for ScrumMasters and related positions have exploded. If you're not yet a ScrumMaster, no time like the present; and if you're not already certified, you should be. Join us in Denver in July, or Edinburgh, UK in October.
Okay, so this is probably false -- unless you're prone to monitor tan. However, it is true that building dashboards in Rally is a piece of cake when you're a trained Rally Power User. Become an indispensible Agilist ... and master the embedded Flappy Birds knockoff game while you're at it. Classes in four locations this summer.
Ouch: it's true. If this has got you thinking, "Better safe than sorry" and "Safety first," we like where you're going. Channel that concern into a Leading Scaled Agile Framework (SAFe) course and you'll be saving your business the money and broken bones of failed-scaled Agile efforts. Check out classes in four locations this summer.
What? You haven't heard about this latest trend? Your execution engine may be humming along, but if it's not tied to a strategy with true customer value you could be moving fast in the wrong direction. Learn how to read the market, align your teams, and plan a roadmap to quickly deliver what your customers want most (it's probably not butter-flavored coffee.) Join us for classes in July and September in sunny Boulder, Colorado.
Check out the whole roster of classes at agileu.com!Rally Software
It took us a long time to make the move to hybrid vehicles, and even longer to electric powered. For decades, the major automobile manufacturers seemed to be ok with the existing state of affairs. Some accused them (and the oil companies) of inhibiting any efforts that moved us away from gasoline-powered vehicles and toward more fuel efficient or alternative technologies. But to their credit, the car companies eventually came around.
Today we’re seeing more and more hybrid and electric cars on the roads than at any other time. You could attribute this to the rising cost of gasoline, the green movement, a desire to be free of the grip of OPEC, a general sense of technological progress and efficiency, or – if you’re like me – all the above.
At the end of the day, it’s a game of survival. Adapt or die.
If you’ve been involved in an agile transition at a large organization, you’ve likely faced a similar fight. Not everyone is so receptive to change. Transitioning to agile methods requires us to evolve. As we look to do so, I believe one of the first areas to examine is the way our organization is structured.
The emphasis on projects has become huge, and as a result, we’ve seen an almost wholesale shift to the ‘balanced matrix’ structure. This is where departments (like Development, QA, User Experience, et al), and project teams work together. The authority sits predominantly with the functional managers of those departments, and to a lesser extent with the project managers (who typically work as part of a PMO department, reporting to another functional manager). The projects are run by project managers who have limited authority. These project teams are ‘assigned’ folks ‘temporarily’ from the various functional managers for the duration of the project. Once the project is completed, everybody goes back to their safe, little functional silo, or gets assigned out to another project team. This is how most software organizations have been working for the past decade or two. And this is considered by many to be a major improvement.
But this structure doesn’t fit well in an agile organization. In an agile ‘team-centered’ organization, the team is the crucial element, not the project. The teams are assigned projects. This is a fundamental shift to how we’re organized in the balanced matrix structure, where projects were assigned people.
The idea here is that when we allow teams to stay together and gel, they get really good at delivering. This team development takes time, and is necessary and inevitable in order for the team to grow, to face challenges, to tackle problems, to find solutions, to plan work, and to deliver results. Well-gelled teams know their strengths and their weaknesses. They have learned how to communicate with one another and to be more productive. The last thing we want to do is break up what has perhaps taken months or longer to create.
So, in a team-centered structure, Team 1 might have a product owner, scrummaster, a few programmers and a tester. Other teams could have a similar makeup depending on the size of the effort they’re working on. Many larger organizations have the additional roles of chief scrummaster, chief product owner, chief technical owner, and chief QA, but they sit outside the teams – mainly for support purposes.
You’re probably thinking to yourself, “This all sounds good, but where did the functional manager and project manager roles go?”
The project manager role no longer exists as it once did. Many PMs become scrummasters or product owners on scrum teams. If they’re not a good fit for this type of environment, they often become coordinators or managers of larger cross-team integrations, managing things like logistics, scheduling and tracking.
Functional managers no longer delegate work to teams in scrum. They play more of a mentor role… a servant-leader to the team, helping them to grow, learn and get better. As we know, scrum teams are self-organizing. They don’t need to be told what to do or how to do it. Teams look to scrummasters for guidance on things like standards and helping to resolve impediments.
If you’ve changed to a team-centered structure, what has been your experience? Have roles changed as well?
We write a lot in the Edge of Chaos blog about visualization, and how helpful it is for project management, problem-solving, strategic thinking and learning. No matter if you’re an executive who wants to contemplate a business challenge from various perspectives, a software developer, or a strategizer, nothing can be as handy a tool as a pen and paper (or, in some cases, a digital screen) to hone your ideas and give them a finished touch. Visualizing ideas helps to drive the point home not only with yourself, but with the others, if you want to make sure that they understand what you mean.
Let me share some of my favourite ways to visualize ideas.#1. An XYZ Coordinate System
I like this way of visualizing as it helps to build mental models that show how 3 factors might influence one another. Yes, they have 2D coordinate systems, X and Y, and I do use them, too, but in the complexity of today’s world where more than two factors often have to be taken into account, 3 D visualization might work out better. Here’s the image that I used in one of my articles to explain how backlog management can be done with 3D thinking, as opposed to 2D (backlog and work in progress). X-axis is work, Y-axis is progress, the X-Y plane is any work in progress AND Z-axis is any other 3d dimension, or a lens, through which one can filter the backlog or work in progress. The red lines in the Z-plane against the X-Y plane represent those various influences, or filtering criteria. The artistic execution might be far from perfect, but this image did help me express my idea better and pass it on to the readers:
I used this visualization to explain a decision-making technique. While the XYZ coordinate system provides some kind of 3D space to a concept, making it concrete, the 4 quadrants can be used to break abstract concepts into pieces. It might be helpful, for example, to write out 4 major areas of concern about a problem or a challenge, look at them and drill them down to smaller resolvable issues. This technique helps to think clearly.
#3. Overlapping Circles
I somehow feel that this pattern have been overused to visualize a very simple overlap of 2 concepts, e.g. one circle stands for “good”, the other stands for “bad”, and the overlapping area is the mixture of good and bad, which is kind of obvious without using circles. So, I’m not very fond of this practice, because it looks a bit trite, but I did use it several times, e.g. to show that business meetings are made up of 3 essential components mixed as in a bowl:
They work well to connect the idea nodes and summarize the concepts that someone already knows well. I’ve written the Mind Maps in Cognition article which suggests some points on when it makes sense to use mind maps, and when not. Here’s the mind map that I sketched as a summary of knowledge that software product owners need to have:
That’s the visualization that I used to explain the idea of a new paradigm for project management tools. I had a sketch of this idea on paper, but this time someone helped me with a nice image:
This molecule glues the core paradigm to the other paradigms, rotating and gaining various momentums, depending on where they find themselves in space at any given point of rotation. The rotation is a symbol for changing goals and organizational environments, and the way they influence project management tools.#6. Sketches in Moleskine notebooks (no grid lines)
I find this especially inviting when a sheet of paper has no grids. This freedom of paper space somehow encourages the freedom of thinking. An A4 sheet of paper does not do this trick for me, because a Moleskine notebook has pages, that can be flipped, and they can be kept for future use as a collection. Also, for some reason I like to start sketching on the right side of the double-page spread, and then continue on the left one, same way they do when they write in Arabic. I do idea sketches for my articles this way sometimes. Here’s the idea sketch for my recent article Visualization: Why the Fusion of Arts and Tech Matters:
“You can’t be pro pizza and anti-gluten.” Jimmy Kimmel
In a recent skit on the “Jimmy Kimmel Live” show, random people in LA who were on gluten-free diets were asked to define what gluten actually was. It became tragically comic when nearly all the people quizzed had no idea. We are too willing to make radical changes to our bodies without really knowing why… Are organizations doing the same thing with Agile? Don’t get me wrong… I have a family member with celiac disease that has painstakingly removed gluten from her diet. You can’t walk down a grocery aisle these days without seeing the word “gluten free” proudly printed across labels of all sorts on shelves. Gluten-Free has become mainstream and accepted into society as a norm. I recall going out to lunch recently with friends and one person was on a gluten free diet. “Lunch would be great,” he said, but he couldn’t eat white grains, sugar, meat, dairy or salt. “Rice and fish are okay,” We ended up going to a local favorite Thai restaurant. He had celiac disease and understood the consequences if he ate gluten.
Ripping the label off Like gluten free, everyone tosses around the word “Agile”so readily from the boardroom to the server room. A recent Google search returned about 19,000,000 results from the word Agile. Tensions abound when the values in the manifesto are incongruent to conventional ways of working. This has lead to interesting discourse. Big A vs little ‘a’ Agile, Agile is Dead, Flaccid Scrum, Taking Agile Back, Consumer Agile just to name a few… Has the “A” word gone viral? Some folks have ceased using a label altogether, resulting in new and effective patterns of work context. What might happen if we ripped the label off and began to focus on effective ways of working? Does a label obligate us to exploring new ways of working?
Customer service agents battle on the front-lines daily. Whether they’re taking inbound calls, answering emails, or juggling chats, it’s pretty important we find a way to make their lives easier (we want them to heart our customers right?).
Axosoft HelpDesk is an awesome, approachable solution to your customer support needs. It has the ability to convert support emails into tickets, manage those tickets, and it comes with a handy customer portal. These three capabilities will equip your team to assist customers fighting the good fight out in the field.
Much like a violinist trying to learn viola, if you’re a user of Axosoft Scrum or Axosoft Bug Tracker then you’ll find yourself serenading away with our Axosoft HelpDesk. Ticket management behaves identically to defect or feature management, which means you can customize their fields, workflows and filters the same way you have in our other products. We highly suggest you try color coding your tickets to make them more pleasing and discerning to the eye. Check out this link to learn more.
Email integration allows all your emails to come into our system as tickets, and is by far the most distinguishing feature of Axosoft HelpDesk (which is getting some love in our upcoming 14.2 release).
Once you set up all the email connections (IMAP or POP3), the system will check the email account every few minutes and pull in new emails as new incidents. That way, everything comes into one central location where your entire team can access and manage the following:
Move tickets through the workflow
Send outbound emails
Keep a history of emails within each ticket
You can even set up auto-replies and gain access to more advanced settings. If you need help enabling any of these features, check out our documentation.
Axosoft HelpDesk’s Customer Portal is a simple, easy-to-use ticketing system. It allows any customers you have defined in the system to login, create tickets, and potentially monitor their ticket’s progress.
This is where things start to get interesting. You see, the best part about Axosoft HelpDesk is its ability to integrate seamlessly with Axosoft Scrum, Bug Tracker and Wiki. You can choose to expose parts of your Product Backlog, Defect Backlog and Team Wiki via the customer portal.
Want customers or internal employees to log a bug? Use the Customer Portal.
Want a place for feature request submission? Use the Customer Portal.
Want customers or employees to access and edit project wiki pages? Use the Customer Portal.
You start to get the picture. Check out our customer portal documentation to learn about how you can get this set up. By the way, this Axosoft HelpDesk synergy with Axosoft Scrum and Axosoft Bug Tracker also works with email. That means yes, you can also have folks email bugs or feature requests into your backlogs as well.
Axosoft Help Desk shines when combined with Axosoft’s project management and bug tracking solutions. If you’re considering trying the product, you can start a free trial today to see what you think. If you’re a current customer, you can also request a trial of Axosoft HelpDesk by going to Tools > Account Administration > Modify Plan.
There is so much more to Axosoft HelpDesk, so expect even more related blog posts in the future. ‘Til then, may the Support be with you!
At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)
If you look at Scott Ambler’s 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.
We can say, “don’t do this,” but that’s not helpful to the distributed and dispersed teams. I would rather be helpful.
For example, in my talk, not the slideshare, I actually said, “Don’t do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.
One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn’t matter if people weren’t fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.
I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.