by Thomas Murphy | September 25, 2012 | 1 Comment
The Harvard Business Review Blog Network published a post from Anne Kreamer about The Rise of Coworking Office Spaces on the 19th that describes a trend that combines a combination of traditional office leasing provided by companies like Regus together with the Open Floor plans that many Agile development teams use (if you are a client see my note on Agile Spaces or look at my earlier posts on the topic). Kreamer notes that Coworking spaces provide the following benefits
- collaborative networks and an ecosystem
- fostering innovation
- simplify starting a business
This last bullet emphasizes the current prime use for such working arrangements a collaborative think tank that provide not only the infrastructure but also the people to bounce ideas off, validate legal issues, etc. While there will be no dramatic shift I do expect to see a continued evolution of our working spaces and Kreamer notes;
It’s just one of the many ways that companies are capitalizing on flexible workspaces for a flexible workforce — a trend we can all expect to see more of in the future.
Gone are the days of the pension and the battle for the corner office. Going away are also the tyranny of a business hierarchy. Which brings to recollection a product naming email thread from many years ago during my product management days in the Smalltalk market. Richard Gabriel railed against the marketing organization for the product name VisualWorks as a name that connoted business buyers wanted to purchase a product that told their developers they were there to work and that we may as well call it Visual Gulag. While you might not think of work in such terms, there is no doubt that the way we work, and the things we value as well as what our companies value in us will continue to evolve. This means a continued move to enhance cross-discipline collaboration and open spaces with loosely defined project team boundaries in a drive to find innovation and exploit business opportunities.
Category: Agile Space Planning Tags:
by Thomas Murphy | September 21, 2012 | 1 Comment
I started a small survey a few weeks back to look at gaining a bit more quantitative information about testing organizations. I have suspended the survey for now (and folded it into the survey we are running with the Integrated Quality Suites MQ reference customers). While we need to do more digging here and strengthen the data set with the input from the reference customers, I thought I would share a couple response charts as food for thought.
First the Tester to Developer ratio. This falls about where we expected though I am sure in a broader market there are more people that would fall in the malpractice areas of 1:10 or 1:20.
And organization style
Category: Metrics Quality Testing Tags:
by Thomas Murphy | September 18, 2012 | 2 Comments
As we work through vendor conversation for the update to the Integrated Quality Suites MQ, we are seeing a tremendous number of interesting developments from the market though often they are fragmented. At the same time it seems that we are being pushed forward to continue to do more and more to ensure that we are building software right and resulting in a pressure for more automation, more tests, more metrics in the: they didn’t work before but if we just do more then it will all be good mindset.
While there is value in this, there are limits to the ability to do more and we find that often we end up with conflicting directives. I believe that as we continue to shift toward a production-centered mentality, away from projects, and continue to progress to Chief Marketing Officer involvement in the development process (oh no!) responsiveness will be critical and in a good way we may turn our metric focus away from a pile of function point-based measures to Customer Satisfaction and ROI. This will change the way we approach testing (and development as a whole because quality will continue to not be some abstract at the end process but a fundamental goal) to meet new kinds of needs from the business. Pushing this envelope is the Keynote from GTAC 2011: Test Is Dead. It is purposefully pushing a point of view that only “those wild internet companies can do” that I believe will settle in over the next 10 years. Rather than the focus on Build it Right, the focus is Build the Right It.
Harvard Business Review’s “Management Tip of the Day” for Sept 18th reinforces this idea
When asked, consumers almost always say they want more options. But their purchasing behavior often indicates otherwise. Consumers are often overwhelmed by the flood of product information and choices available to them. Many report unnecessarily agonizing over trivial purchases. This cognitive overload causes them to make poor decisions, repeatedly change their minds, give up on purchases altogether, or regret the purchases they do make — none of which is good for your brand. Help your customers simplify their decisions. You can reduce choice by getting rid of less popular products. Or you can simplify their choices by helping them navigate their options and giving them trustworthy information they can use to weigh the alternatives.
To often we see to focus on more, more choice, more options, more features—meaning more WIP, more tests to write and run, more, just give me more metrics and best practices and life will be great. Instead we need less, the challenge is which less.
Category: Agile Quality Tags:
by Thomas Murphy | August 28, 2012 | 3 Comments
A common topic area for us to receive questions about is around the testing organization. This includes questions on metrics, size, and structure. With the shift to agile, the increasing growth in utilization of outsourcing, and a pressure to improve quality while reducing costs it seems this is a growing pressure. While we have a good understanding of the issues involved and a feel for the trends, I want to put a few more numbers behind this so as an experiment, I am launching a survey using online tools from Qualtrics. If you are involved in software quality and testing or software development at your organization, I hope you will take time to answer about 10 quick questions in the Gartner Testing Organization survey. I will publish information from this survey and may follow it up with a few more.
Category: Uncategorized Tags:
by Thomas Murphy | August 4, 2012 | 6 Comments
We are underway with our update to the Magic Quadrant for Integrated Software Quality Suites. We are targeting a January release and are beginning vendor surveys and presentations then will move to reference customers and writing. We directed the vendors to focus on the following issues:
Cross Browser/Device Testing – companies are under tremendous pressure to support a variety of browsers and devices. Tools that only run on Windows, can only drive a limited number of browsers, or rely on emulators will weight toward niche markets. Can cross browser be automated and deal with browser specific behavior/implementation?
Agile Development and DevOps – most organizations have some level of agile development and this has been spreading from development to encompass the entire delivery chain with a push around Continuous Integration. Organizations struggle with when to begin functional automation, who should perform the automation, and cost of maintenance. Note that we will update our “Keys to Functional Automation Success” as part of this effort specifically to address agile.
Integration to ALM – tied to agile is the notion that a) automate everything and b) collaborate continuously. This includes connections between requirements and test planning, agile planning, performance testing and APM, and Lab management.
Partnerships – the vast majority of enterprises now make use of a mixture of in-house and outsourced resources.
Extensibility – open source products are beginning to create a significant imprint on the market and part of this is price but another factor is extensibility – how are new devices, gestures, widget libraries, etc. supported, if I have to require a formal upgrade it will be too slow. Forward looking vendors have strong partner networks extending their product and will be evolving marketplaces
Automation stability – organizations need automation that works. We still see very low rates of adoption in functional automation. This is because of cost to build and maintain the automation and a question about when/what should be automated. As many of you hear from me in conversations, the majority of my calls are focused not on “what tools” but on “what practices, which metrics, how many” type of questions.
Category: Uncategorized Tags:
by Thomas Murphy | August 4, 2012 | 1 Comment
I often have calls with clients about technology roll-outs and pilots that “failed” and while there are some occasions where the technology just didn’t work, it is more frequently the case that the user just wasn’t in the right frame of mind to start. Face it, in almost every case, technology has some level of “sucks” associated with it and there are no perfect products. Thus the key in a pilot should be to “Fail Fast” and figure out what those short-comings are, both the product short-comings and your organizational short-comings. Certainly there are some issues that may only come out in time like scalability but these should be dealt with ahead of a pilot by talking to references that match you in scale. In addition there may be rough spots when you move from the “hand-selected” early participants to the “rabble” that might be the rest of your organization. However, a pilot should never “fail” if you design the project for Fail Fast principles. A pilot should identify what are the shortcomings, can you live with them or overcome them (via training, extension, expectation management) and if it isn’t the right product by gaining a greater understanding of what you really need in a product.
Agile teams work in short iterations and use continuous processes to identify failure as soon as possible. They often work from the principle of “minimal viable product” to control a long investment without gaining incite about what is really required via actual use rather than theoretical specification. A recent article by a former chief scientist at LinkedIn states:
Now it’s easy to say go forth and fail! What’s most important is how you fail. The best method is to fail fast. LinkedIn wasn’t the first social network in a very competitive space nor did we know exactly where we were going. It was an extremely tough fight. What allowed us to succeed was our mantra of failing fast in order to survive. We would build products quickly, test them out, many of them failing, then learn about went wrong and try again.
Utilize this same view as you look at shifts to new methods, moving into new tools (e.g. use of Requirements Management tool vs. MSFT Office) by conduction pilots as short experiments that help you understand what cultural shifts, training, and requirements really exist. Look in making some of these shifts not at starting with the biggest full feature product that meets “all your needs” — you don’t know your needs yet! Instead choose more minimal products with which you can gain feedback quickly and zero in on your true criteria. The only true “failure” is a failure from which you don’t learn and improve, one where you blame the product when it reality it was the organization.
Category: Uncategorized Tags:
by Thomas Murphy | May 10, 2012 | 2 Comments
DVCS systems have become popular amongst agile developers over the past few years. However they have mainly lived either in open source projects (often hosted on GitHub or BitBucket) or on smaller teams that would then promote code into the “authorized” or corporate repository. DVCS systems provide advantages in performance for branch and merge operations thus enabling a smoother workflow during refactoring and with teams that may be distributed. The key challenge has been a lack of enterprise tooling to both understand code evolution/history and more importantly support for user access control.
Over the last 6 months we have seen significant investment into support for Git and Mercurial and other vendors who have been delivering commercial DVCS systems (e.g. PlasticSCM). 3 key examples include:
- Accurev – Kando lets you visual branching and process, and provide access control and lets Git repositories to run and be managed in parallel with Accrev native repositories
- Collabnet – has integrated Git to TeamForge providing authentication, a master repository, and life-cycle integration
- Atlassian – new Git-based Stash product provides user and repository management and code traceability between Jira issues and changesets
This growing support will speed migration for organizations that currently use Subversion but are struggling with branch/merge overhead.
Category: Agile Open Source SCCM Tags: Accurev, Atlassian, Collabnet, Git, Mercurial, PlasticSCM
by Thomas Murphy | March 19, 2012 | 1 Comment
Saw a great presentation on Agile PM which is applicable to any organization trying to understand how to get to Enterprise Agile or to move beyond the baseline of Agile development teams. This presentation by Nina Schoen from Getty Images discusses how they made a migration and the use of Agile/Lean principles to guide decisions. She addresses both how to work with the business, metrics, team dynamics and the culture change issues. One of the great quotes comes from a partner they used, Net Objectives that basically states: Agile fails when we don’t first address the real root cause of IT failures—too many, tool large, poorly understood projects. A lot of great content in a 30 minute presentation.
Category: Agile Metrics Strategic Planning Tags:
by Thomas Murphy | March 19, 2012 | Submit a Comment
Rally has been in their new offices for a little over a year now. In general they are very happy with the way that things have worked out but they have also seen that not all ideas are as useful as originally planned. Like agile development, this brings to note that a key part of productive office space is the ability to learn and adjust. A change to a radically different floor plan using a lot of open space while having many benefits will also be highly disruptive to team members with many years working in a traditional office space. Start with a pilot and learn the right fit for your organization.
Rally’s office has many concepts that are common in modern development organizations: lots of open space and natural light and wallboards showing various build and quality information.
But is also has some more unique aspects such as the overhead wiring and movable partitions. The combination of these provide for a lot of flexibility in the floor plan without the challenges of raised floors and cubicle walls.
Overall the space plan is designed with engineering clusters and open areas that enable design sessions and kind of a solar system of rings working out to support, marketing and sales. This provides connection but also enables the right level of focus and sound control. As noted in Build an Agile Culture With Extreme Floor Plans and Cubicle Demolition get the team involved, and develop the space with specific goals and recognition of constraints including your team members.
Category: Uncategorized Tags:
by Thomas Murphy | March 2, 2012 | 1 Comment
VersionOne has a constantly evolving floor plan as the company continues to grow but at core in the design has been the balance between privacy/focus and collaboration. In general this means nearly everyone works in open areas but there are many private rooms available for phone calls or other times when privacy is required. A key point made by the company in the space plan is the theme of collaborative by design not as result of cost cutting. Too often development teams get migrated out of offices and into cubes from a perspective of cost not because it will be better for the developers. (A common subject for many Dilbert comics). With Open Space as opposed to Cubicles they feel you actually end up with a feeling that you have more sq feet per person. A key comment is:
The costs associated with task-switching are higher in an open environment but you’re also much more connected to the “vibe” of what’s going on. And, I find you’re more aware of what’s going on in the larger organization by having more conversation with people as they pass by – it’s not just the people you’re sitting next to.
Here is a view looking from the second story down to the primary developer area. Note the CTO is at the desk in the upper right corner. While the space was very open, it was very quiet and there is great natural light. This area opens out onto a patio for summer bbqs.
Category: Uncategorized Tags: