Check out these Reactive trends on the JVM, including a look at what Reactive is, patterns, and event logging.

Insights on how to make an average velocity concept a powerful tool for your Agile team.

Apache Struts 2 and SpringMVC, these two are the most popular and much talked about Java web frameworks today. Many of you might have worked with both of these frameworks, but which is one is better to use? What are the basic differences between both of these frameworks? Well, Apache Struts 2 is an elegant and extensible framework that is used for creating enterprise-level Java web applications. It is designed to streamline the development cycle, starting from building to deployment and maintenance of the application. In Struts, the object that is taking care of a request and routes it for further processing is known as “Action”. On the other hand, Spring MVC is a part of a huge Spring framework stack containing other Spring modules. This means that it doesn’t allow developers to run it without Spring, but the developers can run the Spring Core without Spring MVC. The Spring MVC (Model View Controller) is designed around a DispatcherServlet, which dispatches the requests to handler with configurable handler mappings, view resolution and theme resolution. While the objects responsible for handling requests and routing for processing in Struts called an Action, the same object is referred as Controller in Spring Web MVC framework. This is one of the very first differences between Spring MVC and Struts2. Struts 2 Actions are initiated every time when a request is made, whereas in Spring MVC the Controllers are created only once, stored in memory and shared among all the requests. So, Spring Web MVC framework is far efficient to handle the requests than Struts 2. If we talk about the features, Struts 2 and Spring MVC framework caters different level of business requirements. Let’s take a look at features offered by both of these frameworks. Struts 2 features Configurable MVC components, which are stored in struts.xml file. If you want to change anything, you can easily do it in the xml file. POJO based actions. Struts 2 action class is Plain Old Java Object, which prevents developers to implement any interface or inherit any class. Support for Ajax, which is used to make asynchronous request. It only sends needed field data rather than providing unnecessary information, which at the end improves the performance. Support for integration with Hibernate, Spring, Tiles and so on. Whether you want to use JSP, freemarker, velocity or anything else, you can use different kinds of result types in Struts 2. You can also leverage from various tags like UI tags, Data tags, control tags and more. Brings ample support for theme and template. Struts 2 supports three different kinds of themes including xhtml, simple and css_xhtml. On the other hand, Spring MVC framework brings totally different set of features. Spring MVC features Neat and clear separation of roles. Whether it is controller, command object, form object or anything else, it can be easily fulfilled with the help of a specialized object. Leverage from the adaptability, non-intrusiveness and flexibility with the help of controller method signature. Now use existing business objects as command or form object rather than duplicating them to extend the specific framework base class. Customizable binding and validation will enable manual parsing and conversion to business objects rather than using conventional string. Flexible mode transfer enables easy integration with the latest technology. Customizable locale and theme resolution, support for JSPs with or without Spring tag library for JSTL and so on. Leverage from the simple, but powerful JSP tag library known as Spring tag library. It provides support for various features like data binding and themes. Of course, Struts is one of the most powerful Java application frameworks that can be used in a variety of Java applications. It brings a gamut of services that includes enterprise level services to the POJO. On the other hand, Spring utilizes the dependency injection to achieve the simplification and enhance the testability. Both of these frameworks have their own set of pros and cons associated with it. Struts framework brings a whole host of benefits including: Simplified design Ease of using plug-in Simplified ActionForm & annotations Far better tag features OGNL integration AJAX Support Multiple view options and more However, the only drawback with Struts 2 framework is that it has compatibility issues and poor documentation. On the other hand, Spring MVC provides benefits like: Clear separation between controllers, JavaBeans models and views that is not possible in Struts. Spring MVC is more flexible as compared to the Struts. Spring can be used with different platforms like Velocity, XLST or various other view technologies. There is nothing like ActionForm in Spring, but binds directly to the domain objects. Code is also more testable as compared to the Struts. It is a complete J2EE framework comprising of seven independent layers, which simplifies integration with other frameworks. It doesn’t provide a framework for implementing the business domain and logic, which helps developers create a controller and a view for the application. However, like any other technologies or platforms, Spring MVC too suffers from several criticisms related to the complexity of the Spring framework. Final Verdict Either framework is a great choice. However, if you’re looking for the stable framework, Struts 2 is the right choice for you. On the other hand, if you’re looking for something robust, SpringMVC is perfect. Ensure that you review your exact requirements before choosing the framework!

A list of fun and, oftentimes, true quotes about DevOps and software development.

A definition of verification and validation in regards to automated testing, and a guide to using them in your workflow.

A brief history of story points, and why they're not as useful as they may seem at first glance due to the complexity they introduce.

An analysis of how much of DZone's audience lives up to the lofty goals of the Agile Manifesto.

Get a crash course in understanding microservices and the difficulties in implementing them.

From time to time I’ve been heard to say: “Agile is Punk.” But I’ve never explained myself. I’ve also been heard to say things life “Agile is about democratising the workplace” but I’ve never explain myself there either. Let me try… What I mean when I say this is: Agile (software development) has a lot in common with Punk rock. To me the important thing about punk rock was that it was about people trying it - music, their own thing. Anybody trying to play music, anybody forming a band, anyone who had a novel idea trying to get a record contract. Yes, even if they couldn’t play an instrument they could have a go, and who knows, maybe they would learn as they went. (I should say that while I’m old enough to have been around when punk was I’m not old enough to have been there. Both post-punk and post-disco influences were at work in the New Wave music which was common when I came music listening.) Punk had a democratising effect on music. Music has aways been of the people, anyone can listen, anyone can try to sing - although I’m not very good at it even I can try! But the music industry was something different, performing, recording - there were barriers there! Punk tore down barriers. Punk opened up the recording industry. Punk opened up music. Agile opened up the software process industry. Before Agile official software processes were pretty locked down. You had to be an academic or expert/consultant to dabble in that space. Programmers who worked in under official software processes were on the receiving end. Agile said: “Your opinion is important too.” In truth music has always was been open to everyone, just not the recording industry. And in software development processes were open to anyone, most programmers did not work under an official process, mostly it was common practices which, if they worked, were probably more effective than official ones. Unfortunately these unofficial work practices came with guilt: because we did not do it the way the books said we should. When faults occurred we blame ourselves for “not doing it properly”. Agile says: “Everyone involved with software development should have a voice in deciding how to work, it can be improved and you don’t need to be an expert, academic, consultant or certified member of some body to express that view.” That also makes it democratic. I don’t mean democratic in the sense that we all get to vote, I mean democratic in the sense that it is power is vested in the hands of the collective people. Everyone has a voice, everyone can participate, and those who hold executive power do so by the will of the people. Agile is about giving everyone a voice. Like Punk that means accept that those who don’t have much skill are also entitled to a voice. Funnily enough, I’ve long held that any punk band that made a second album weren’t punk anymore because they were part of the industry, they were now experts! The same is true with Agile, hang around for long enough (like me) and you are no longer an outside but an insider, an expert. Increasingly we see Agile heading outside of software development. When this happens it becomes necessary to ask: What is Agile? My answer is: Democracy. Agile is about valuing everyone, agile is about giving everyone a voice, agile is about putting the power to change the workplace (process, systems, norms) into the collective hands of the people who work there. Yes at times it feels revolutionary, but there are fellow travellers, it is all a Theory-Y movement.

Written by Jim Magers for LeadingAgile. When I’m teaching an agile bootcamp class and talking about work in process, I always make a point (usually multiple times) to tell the attendees that agile is about finishing work…not about starting work. I reinforce this by pointing out that you can have a glorious looking burndown chart for the duration of the sprint but completely fail in your mission to meet your commitments and finish stories. The team can be burning down hours beautifully on a daily basis, with the remaining task hours looking like they are tracking right along the ideal line, and then boom… It’s closing time for the sprint and no stories actually got completed. Remember that notion of building working, tested software? Didn’t happen. The team started too many stories at once and ended up not being able to bring any of them across the finish line when the bell rang. This notion of finishing work applies to sprint planning as well. If you short-change the time it takes to do good sprint planning, and the team meanders off to begin writing code and test plans too soon, there is a risk that the team is going to struggle to be successful. Remember what we do in sprint planning. Consider velocity, and load the sprint backlog with high priority stories from the product backlog. Check. Determine capacity for the team to work on sprint tasks over the coming sprint. Check. Break stories into tasks and determine who is doing what. Check. Make sure the work is going to fit. Check. Commit to the work. Check. But what can happen when you don’t take the time to thoughtfully break down tasks and estimate hours of effort? Consider the following burn down chart. In this example, the team left sprint planning thinking that they were committing to 830 hours. But just two days into the sprint they discovered additional task hours and instead found themselves in the awkward position of actually needing almost 1200 hours of capacity to complete the committed stories. Guess what…they did not have 1200 hours of capacity to give, especially since they were now a full two days into the work. In looking more closely at their burndown chart over the course of the two-week sprint, it took them almost 6 days of work to get back to the point where they had 830 hours of work left to do. Six days just to get back to where they thought was their starting point when they concluded their sprint planning meeting. And surprise, they didn’t finish the sprint successfully. So, don’t short-change the value that good sprint planning affords. Yes, it takes time. Yes, it can seem tedious. Yes, the team is anxious to get started. But good sprint planning pays dividends. Remember that it is about finishing work, and not about starting work.

Business leaders like to be in control of every aspect of their operations, but if any element is outsourced, that sense of governance becomes much more difficult to maintain. Outsourcing can be appealing to organizations looking for talent at reasonable costs - it just takes significant planning to pull off successfully. When a team is in a different location from the company, there are a number of challenges that must be overcome. We will look at what some of the biggest issues are and how you can appropriately manage an outsourced quality assurance team. Obstacles of outsourcing While outsourcing can have a lot of advantages for businesses, the number of roadblocks can be intimidating for many enterprises. Here are the biggest challenges to prepare for: Information sharing: When you don't see individuals every day, it can often be easy to forget to relay important messages. Communication in this situation is imperative, as it could affect the overall operation of the application. As soon as a request is given, there should be seamless transfer of knowledge to ensure that everyone is on the same page and that the project proceeds as expected. This will eliminate any redundancies and lower the overall development cost. Engagement: Many outsourced teams have a difficult time becoming personally involved with their projects. This will also affect their ability to collaborate effectively with other teams in the business, ultimately hurting program quality. Organizations must have a strategy to keep these individuals motivated and provide them with the tools to succeed. Technology/skills: An outsourced team may use different pieces of technology or have skills separate from what the organization was looking for. For example, if the company really wants to move to agile software development, but the outsourced group still uses waterfall methods, that could create problems down the road for their software development initiatives. Similarly, the business must ensure that the outsourced individuals have the skills necessary to meet corporate goals and spur innovation through their app testing. How to regain control Although total governance of outsourced assets won't be possible, there are still some things that organizations can do to take control of these teams and ensure that they're fulfilling business objectives. Australian outsourcer Beepo suggested a consistent schedule for gathering feedback and using technology like the cloud and test management tools. Let's dissect each of these ideas. Many outsourced teams are often left by the wayside when it comes to communication. This can reasonably lead to mistakes being made and leave the members feeling apathetic toward their work. However, by setting up regular video conferences and requesting feedback, outsourced individuals can feel empowered to express their opinions and become a larger part of their projects. This will also help build trust and motivate teams to collaborate more. Using tools like test management and the cloud can also be helpful when working with an outsourced team due to the fact that they provide a singular platform for all users. This means that the outsourced and in-house teams can be working on the same project at the same time, with any changes being made in real time. This will not only reduce redundancies, but it creates accountability and ensures that tasks are being addressed according to their priority. Considerations to make when outsourcing Whether you're looking to outsource, or simply make your outsourced team better, there are some key items to address. Ashok Mani from AppLabs noted that organizations must look into a provider's engagement models, mobilization efforts, communication plans, security and scalability. These elements will be essential to clear up before trying to manage a team. "While organizations are deriving value from outsourcing software development, outsourced software testing will maximize returns from their investments and provide the right level of objectivity and rigor required to create a high-quality product," Mani stated. "If an independent QA and testing service provider is chosen whose focus is on ensuring quality products/systems are implemented, benefits will be fully maximized." Outsourcing a quality assurance team is going to have a few challenges for businesses. But by preparing for these obstacles, they will be able to manage the outsourced group more effectively. Having a communication plan and technology available will be essential to working well with the team and improving development operations.

I am sure by now most people understand that there is strong correlation between employee satisfaction and business results. If you need more convincing have a read of these two articles: Forbes & Research Paper So how do you best go about measuring it? On my current project I have decided to go with the following 4 questions: I would recommend this account and my project as a good place to work I have the tools and resources to do my role well I rarely think about rolling off this account or project My role makes good use of my skills and abilities For those of you who have read Jez Humble’s “Lean Enterprise”, these questions will look familiar. I have adopted them to the project setting that I work within. We have just set out on a cultural transformation to become truly Agile and adopt DevOps in a large complex legacy environment. To me measuring the above will give me the best indicator that we are doing the right thing. Of course there will be other measures who determine the quality of the outcomes and the levels of automation among others, but changing the culture of an organisation is critical if your Agile and DevOps adoption is to be successful. I will report back throughout that journey to tell you what my experiences is with the above questions. IT delivery is complex and it is not always clear what the right solution is. I found in the past that it is near impossible to create processes and tools that work by itself, you need to have the right mindset that people use the processes and tools with the right intent. It’s very frustrating when you implement great automation only to see a few months later that the solution has degraded. It is with hindsight that I understand that the solution is to not just implement process and tools but to instill the right culture and mindset for progression, a culture where we blamelessly identify a way to avoid the same mistake again rather than looking for the person in fault, a culture where we strive for automation and lean processes and are not concerned about the size of our teams or budgets, a culture where you don’t have to protect your fiefdom and where you are happy to collaborate with others to solve problems no matter where the root cause lies. I think we all in IT need to understand this dynamic between employee satisfaction and outcomes better, I for sure believe that I have come across a magic potion that I aim to bring to all my future projects. About these ads

Are you really sure what makes a programmer productive? Is it VIM instead of Emacs, the latest Haskell web framework or your favourite NoSQL database? Sorry, but if you focus on tools, frameworks or even processes, you got it backwards! Real programmer productivity starts at the very beginning: Proper requirements. Why you as a developer must care - not only the business staff ! Sure, the founder/product owner/team lead/name of the month must care to build something that a customer ultimately pays the company money for. But what about it from a developer’s view? Ever been in the situation where someone shouts over the table: „Just start building XYZ right away, if any questions pop up, we will deal with them during development. We got a head start anyway“ ? We call that: Start first, finish never. Nothing beats building something, where half of what you are building is actually still unclear. How do you know you are done DONE? Not surprisingly, not knowing 100% „what“ to do, leaks a lot into „when are you finished?“ „Oh, we just forgot this…and that!..And actually it should also be doing this! That point of the feature…dunno really?“ And how do you go about testing unclear requirements? This has nothing to do with your favourite BDD tool of the month, or your freaking out if someone does not always test first. (Even though we think there are some, let’s call them preferences, that make building software easier.). If the input is unclear, tests are unclear and the output is even more unclear. You are always super-motivated, right? But the worst part is, that frequent unclear requirements are a sign. A sign that your business people are unsure of what your customers really want/need/pay for. Unfortunately this also means, that a lot of the stuff you build is for the trash can. Nothing keeps programmer motivation and ultimately productivity higher than repeatedly baking bread and throwing it in the trash while it is still hot. What exactly is a proper requirement ? Now what exactly is a proper requirement? Is it a sentence that is written on an index card and starts with „as a user I want to be able to use my Asian CCB credit card?“. Nope. We actually came up with a fancy sounding process for generating and checking proper requirements. We will go into detail on the individual points in our next blog articles, but here’s the abstract spoiler for what a proper requirement is. (Oh, and we'll spice it up with real-life examples from the requirements engineering for the new BMW (car manufacturer) website a while ago.) A proper requirement has (1) been worked out with business people AND programmers, with two-way street communication. It has (2) been repeatedly deconstructed. deconstructed. deconstructed. And it has (3) been defended, which includes what we call „angling“ and „skinning“. STOP it already ! I'm a programmer, requirements are not my job! Yes, in bigger organisations you most often have dedicated business analysts, whose sole job is to iron out detailed requirement specifications before they get passed to „implementation teams“. And in dreamland this all works flawlessly, and you just sit down and start coding, but in reality not so much. Anyway, the smaller an organisation gets, the more a programmer becomes a hybrid. The founder might shout across the table: And you as a „programmer“ have to not only sort out the implementation, but also what the hell this is all about. In any case, you should be a professional ! As much fun as it might be to read through he upgrade path of AngularJS 2.0 instead of accustoming yourself with your customers problem domain and requirements : At the end of the day, as sad as it might seem, your technical skills, voice of frameworks or algorithms are only a part of your day-to-day job. And the basis for all development work is : proper requirements. Next Step: Share your experiences in the comment section or on our blog, subscribe to our newsletter and stay tuned for the follow-up articles!

Former Executive Vice President of HP Software and Operating Partner at Silver Lake Partners Brings Deep Experience to Accelerate Continuous Quality and Digital Engagement Boston, MA – June 25, 2015: Perfecto Mobile, the world’s leader in mobile app quality and experience, today announced the appointment of George Kadifa to its Board of Directors. As a Board member, Kadifa will expand Perfecto Mobile’s vision towards enterprise digital engagement and accelerate the momentum with Agile and DevOps teams. Kadifa has extensive expertise in growing and managing technology businesses, having held leadership positions at HP, IBM, Silver Lake Partners, Corio, Oracle, and Booz-Allen & Hamilton. As Operating Partner at Silver Lake Partners, Kadifa was responsible for driving the growth of a 24-company enterprise portfolio from the firm’s large-cap investment fund. Most recently, Kadifa served as Executive Vice President of HP Software and Strategic Relationships, where he led HP’s multi-billion dollar software portfolio under the direction of HP’s CEO. “We are delighted to welcome George Kadifa to Perfecto Mobile’s Board of Directors,” said David Reichman, Chairman of the Board at Perfecto Mobile. “His extensive leadership experience at the top global technology companies, paired with his deep operational knowledge, will add a valuable dimension to the Board as he supports Perfecto Mobile’s vision into the next phase of digital engagement.” Kadifa is currently the Managing Director at Sumeru Equity Partners, Director at Velocity Technology Solutions and serves as a trustee for the University of Chicago Booth School of Business. "As someone with first-hand experience leading both a new breed of companies as well as some of the largest technology organisations in the world, I have come across many companies who set out to change an industry,” said Mr. Kadifa. “It is quite rare to find a company such as Perfecto Mobile, with superior technology, a vast market to penetrate, and a visionary executive team. In addition, it offers a highly disruptive business that is transforming legacy tools and waterfall methodologies to an open and continuous approach, matching the way DevOps, Agile and Mobile teams work. I am excited to work with CEO Eran Yaniv, the Perfecto Mobile executive team and the Board to support Perfecto Mobile’s explosive growth becoming the standard in the mobile and digital quality market.”

COLOGNE, Germany – June 22, 2015 – ParStream, the IoT analytics company, today announced its participation at the TDWI Munich Conference 2015, one of the largest gatherings of expert Business Intelligence, Big Data and data warehousing leaders and educators in Europe. The conference will take place June 22-24, 2015 at the MOC Order and Event Center in Munich, Germany. Albert Aschauer, Sales Director DACH at ParStream, will present on requirements for an analytics platform for the Internet of Things (IoT) based on real-world use cases from the renewable energy and telecommunications industries. Big Data, fast data, edge analytics and real-time insights are driving new technology innovation to meet the demand for getting more value from IoT data. Additional details on the speaking session are below. What: “Requirements of an Analytics Platform for the Internet of Things” When: Monday, June 22, 2015 at 11:35 a.m. CEST Who: Albert Aschauer, Sales Director DACH at ParStream Where: MOC Munich, Germany – Room F112 To schedule a one-on-one meeting with Albert Aschauer and ParStream at TDWI Munich Conference 2015, send an email to events(at)parstream(dot)com.

Written by Joel Bancroft-Connors for LeadingAgile. Okay, so your enterprise wants to start an agile transformation. Good for you! We’ll assume you know why you are doing it, what the values are and that it’s not an overnight process. That still leaves a question of where in the organization do you start? Do you start with a small scale team level approach? Do you get executive sponsorship for a top down push? Do you work through the PMO? And what about middle management? The answer is, yes. Let’s look at the various entrance vectors for an agile transformation, and why they can fail. From the Team Up When I first gained a formal understanding of agile (like many I’d been doing it for years without realizing it), my basic Shu understanding of agile was very team and individual focused. I think my background in customer service made this a very natural place to go to. As a natural extension of this I believed that “agile must grow from the teams”. If you believe you are agile, you will be. It was at this time I first came up with my “Better people lead to better teams, better teams to better projects, better projects to better products, better products leads to better companies and better companies will make a better world.” philosophy. Unfortunately, this is not unlike the kid with a blanket tied around his neck that jumps off his parent’s roof, in the belief he can fly. Belief will only carry you so far in the face of the law of gravity. A team level agile transformation can only go so far in the enterprise before it runs into the impediments of large organizations. From the Top Down At the other end of the spectrum you have agilists that firmly believe an agile transformation must come from the executive level. Without their support, you can never conquer the agile anti-bodies and organizational impediments. The most common problem with this method, is a failure to commit. The executive says “we’re going agile” and may even hire some consultants to come in and help. Only like the product manager who doesn’t get the shift to being a product owner, the executive does not take part in the transformation. Mandates and visions from the C-Suite rarely succeed unless the executives are willing to invest their time directly into the effort. Even if they do, they can run into strong resistance from the middle without constant support from the top. Meet in the Middle For a time I believed that this was the secret to success. Find a team that wanted to do an agile pilot and get the executive to support this from the top down. This too is fraught with risk. I learned this was not unlike burning the candle at both ends. Pretty soon the middle is melting. Even if the agile pilot was successful, two things would rise up to crush it. The first being most agile pilots are small scale, high performing projects that won’t scale across the organizational impediments. The other problem was that the managers in the middle had a tendency to become detractors out of sheer fear of how this would change their role. Which led me to to the realization that without middle management bought in and supporting, you could not be successful. This launched me on a quest to help educate managers on what it meant to be a manager in an agile organization. While teaching managers to move from managing tasks, to enabling their teams was certainly valuable, it was not the magic entry point to start a transformation. It did build on my “better people” belief in that I was helping managers to support their directs better, even if they were not doing agile development. That didn’t help me with finding the vector to start an agile transformation. The PMO My focus on better managers, combined with my PMI background, led me to explore driving an agile transformation from the program management office. I really thought I was on to something here. The PMO typically owns process or has a lot of influence on it. And as peers to the middle management can exert some strong influence with them. The problems though came from all directions. Teams have a somewhat understanding wariness for the “process of the month” from project managers. “These non-engineers want to tell us how to write software?” Next, while the PMO might be able to get an executive sponsor, more often than not that sponsorship extends only as far as the kick-off meeting. And while the PMO does own process, because agile calls for a fundamental change in how people managers interact with their directs, those managers are usually highly resistant. So the bottom, the top and the middle all have their challenges for originating an agile transformation. So what do we do? A Total Approach While I was exploring coaching better managers, LeadingAgile ‘s founders, Mike and Dennis began to realize that only a systematic approach would work to successfully transform an enterprise scale organization to agile. By establishing an agile structure, governance and metrics, a company could bring clarity to their requirements, accountability (and ability) to the teams and be able to measurably track progress through working, tested software. This approach doesn’t focus on just one approach vector. Instead it sets up an agile transformation plan from portfolio, through the program level (product owner teams) to the delivery level. When the agile pilot is done, it’s not a cutting edge XP practice or Lean Startup. Instead the pilot is testing the very first step the rest of the organization will also take. The executive sponsor is directly involved, much like a product owner should be. The managers not only know what is happening, they are directly a part of it and get the support they need to be able to support their teams, not drive them to a death march release. And of course the teams get the hands-on help to make a transition to a Shu level agile framework, the first step in a multi-legged journey of an agile transformation. Not unlike Agile itself When we talk about creating a stable agile team, we often use the slice of cake analogy. The Scrum team (to pick an agile framework) should have all the skills needed to release an increment of potentially shippable product. An agile transformation needs to be a slice of cake through the organization, with everyone an equal player in the transformation. When we talk about enterprise agile release ceremonies we have release planning, sprint planning and the standup. With an agile transformation, the portfolio is the release planning, the program is the sprint planning and the teams the daily standup. Conclusion If you want a successful enterprise-scale agile transformation, you can’t start at the top, the bottom, or the middle. You have to start all along the continuum, at the same time. And for me, it’s been a realization that my “better people, better teams” philosophy isn’t a “one leads to the next” progression scale. Instead you have to work with the company as a whole, to make all levels better, together. I still believe better companies will save the world and that’s what I’m doing when I help a company do an enterprise-scale agile transformation.

Written by Andrew Graves for LeadingAgile. People don’t buy what you do, they buy why you do it. – Simon Sinek Over the last few years I have come across the notion of an Agile Ecosystem and several different thoughts around what constitutes an Agile Ecosystem. I have seen people in the industry refer to the Agile Ecosystem as a number of practices used together to achieve a delivery team’s agility goals. For example, the marriage of Scrum, XP, DevOps and Kanban. I think leveraging the best of breed in all of these areas makes perfect sense. However, the Agile Ecosystem is much bigger and needs to support the business as a whole. To drive sustainable agility and continuous improvement, an ecosystem must be built and maintained at an enterprise level. So… how do you go about building a high performing ecosystem that can provide value and continually delight customers? Start With Why It starts with Why… In other words what are the business drivers for making the organizational transformation. Why are you transforming? It may be to increase your market responsiveness, improve quality or greater predictability. Whatever it is, it needs to be clear. When the why is understood and transparent, the trek toward an agile ecosystem that supports the entire enterprise can begin. The trek starts with defining the end-state vision of your transformation and putting structure, governance and metrics in place to support the transformation. When you have clarified why you are going through the transformation, the next step should include forming teams at the delivery, program and portfolio levels. Then setting up a clear governance model and a way to demonstrate measurable progress. When all of these things are in place, the journey toward enterprise agility can begin. With the end-state in mind and a shared understanding of why, it’s time to get clarity on the team structure so governance and metrics can be applied. In my next post, I will touch on the teams in a scaled enterprise agile ecosystem and how they need to work together to deliver value to the customer.

yesterday i was speaking with a gaggle of early stage tech entrepreneurs about lean startup. they were eager to learn more about about hypothesis testing. newbies wanting to learn about the lean startup approach. yet they were falling prey to what i call the “solutionizing bias”. they only wanted to talk and think about solutions. and making sales. it’s so tempting, easy and natural for founders to fall for that trap. as entrepreneurs, we’re naturally optimistic go-getters. we have a solution for every problem. we want to help out. yet when you’re building a new product, you don’t know whether your solution is important for your customer. if you don’t prove that first, then brace yourself for a long uphill battle. your solution solves a problem your customer has. the customer cares about their problem, not your solution. before you think about solutions, you need to know whether the problem your solution solves is important. in your customer’s eyes. that’s why validating your product idea is so important. first ensure that the problem you’re addressing affects a large percentage of your target market. if you focus on your solution only, you won’t know which problem is worth addressing. it’s blinding. imagine you’re reading a market research report about the biggest problems of your target market. in that report, there is a pie chart. let’s say your prospects have 4 different problems: a, b, c, d. 40% consider a their main concern, 30% b, 20% c, and 10% d. yet, you’ve already built a solution. you realize it addresses problem d. for the same amount of marketing effort, you’ll get 4 times less results than another founder who addresses problem a. in my experience with building products, i’ve managed to build products that addressed problem e. in other words, it was a problem i thought the market should have, but actually didn’t. i was dead in the water. i write about an example like that, and how to prevent it from happening to you, in launch tomorrow . while it’s critical to think in terms of sales you’re going to make when you start a business, first check if you are addressing a meaningful problem first. one that a big chunk of your market thinks they have. and that they’re willing to pay for a solution. then you set yourself up for hockey-stick growth. only then do you build a money-making machine. otherwise, you might as well be a missionary. if you follow the one-day launch sequence in launch tomorrow , you’ll get a decent blueprint to do exactly that. build what your customers want.

concerned you might be not lean if you raise funding? that’s actually a pretty common myth related to the lean startup approach. let me ask you this. have you ever received a “recycled” present? while it’s clearly new, it doesn’t actually match your interests. in fact, you know that the giver received that present from someone else a few months earlier. it’s likely, therefore, that they never opened it, and just gave it to you. that’s similar to the day-to-day experience of a tech startup investor. i actually worked at a vc fund in the past. more on that in future emails. download a free chapter of launch tomorrow to get in on the action. many times a day, vcs get pitched equity in a tech startup. the founders don’t want the equity. they prefer cash. this immediately reduces the equity’s perceived value, in the vc’s eyes. in some cases, screams desperation. if the founders, who have lots of equity they got somewhere else, are willing to give it away…what does it say about the company’s value? about its prospects? about what the founders believe about the company? a common question that i get from people first looking at tech startups is why tech startups need so much money. after all, it shouldn’t cost that much to throw a product prototype together. isn’t it all just self-serving hype? not always. there are five strategic reasons to raise money in the tech startup world: funding customer acquisition hiring top talent the “land grab” the “pre-emptive strike” the cash flow shortfall so, starting from the top. in all but a handful of businesses, if you can’t buy customers, you don’t have a business. sometimes an idea takes off and goes viral. for the mere mortals out there, though, you need to figure out how to acquire customers and serve them profitably. paid advertising, in particular, has a bad name because it’s easy to misuse with other people’s money. it’s easy to fool yourself and others that something is happening, unless if you know what you’re doing. admittedly, most investors aren’t keen on providing money just to acquire customers, unless if you have already proven you can do this. turn $1 into $4. or $40. a marketing expense can reliably generate profit. recruiting talent to help you execute also costs money, particularly if you are breaking new ground technically. figuring out how to scale certain technical problems (like search or constructing social graphs) requires serious technical chops. the number of software engineers capable of doing that is pretty small. and the first guys who scaled google, for example, were self-taught. moreover, to be blunt, the guys in most cheapo emerging markets live in much smaller markets. they’ve never had to solve these problems in their home country. so you need to hire smart people and keep them happy. now–we get to the really good reasons why raising money is a good idea. the strategic ones. if you and your competitors are creating a completely new market, there is a land grab going on. whoever can get the most market share–wins. there’s an old rule of thumb from davidow who ran intel’s marketing during their high growth phase. having at least 30% of market share leads to consistent profitability in most niches. at that point, you can influence what happens. until you get to that point, you’re a commodity vendor. so while it can be a bit abstract, getting a strong footing in a niche will help establish you as a player. if you’re in a niche where this is happening, suddenly paying for growth has whole new meaning to investors. you only need to be a little bit better to beat out the competition, after all. the pre-emptive strike is similar to the land grab, but more defensive. let’s say you are a cheeky bootstrapper. you enter a market adjacent to niches already inhabited by companies with deep pockets. you’ll be at a loss when they decide to enter. for example, google entered the search market, knowing there were a lot of well-funded competitors at the time. yahoo, lycos, and altavista to name a few. moreover, there were big tech players like microsoft who had kind of missed the boat, but still had a lot of money. they could catch up quickly if needed. think bing. if google had tried to bootstrap their way into the market, despite having better technology, they could have lost. instead, they got funding. they built their technology to be completely scalable, while building up goodwill with users. then, after 6 years of funded growth, they finally introduced advertising to monetize the growth. in 2004, they launched adwords. last but not least, there’s the cash flow shortfall. this is more common in tech companies that combine hardware with rapid scaling. in essence, though the same financial problem happens across the sector. there’s a long list of well known companies which blew up, despite having a sales growth trend: osbourne, spectrum. that’s right. high growth, high sales, high profits, yet low cash inflows. if there is a long time gap between a sale and getting cash, the company won’t have enough cash to fund operations. scaling their operations becomes impossible without that. you may need an exponentially growing staff to service your exponentially growing revenues. you need inputs like parts for a hardware company–also at an exponentially growing pace. unlike in software, manufacturing at scale is complicated and costly. should you think this is a throwback issue from the 1970s, what about the internet of things? what about hardware startups today? so there you have it. five legit reasons to raise money for your startup. if you want to get on that path, you’re much better off using the lean startup approach. don’t take external money, if you don’t need it. stop selling yourself (and your business idea) short. validate your idea. with launch tomorrow , you can be certain that you’ve proven people want to buy what you’re selling. or thinking of proposing. or building. build the right product. make sure you can acquire customers profitably. then get funding. and break out the bubbly.

I’ve been questioning my principles lately. One that’s been troubling me is a principle behind the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” I always read this as “don’t start working late when things get busy”. I worked in a company that were really good at practising this. They almost never worked late. Quality was exceptional, tests many, bugs rare. Releases could be sent to customers whenever they need. Is never working late always the best policy? Applying pressure to a team, to deliver more before a deadline is a more common scenario. Rather than focussing the team on what’s important it can induce a state of panic. People are encouraged to stop thinking and “do” faster. Stupid busy culture emerges. A culture where working late is expected and results in a death spiral of poor quality. You’re always far away from a release. This seems very common and a difficult mindset to unravel, but are there more positive reasons to work late? I see people working late when they’ve become passionate about the work they’re doing. If they’re equally passionate about quality is this something I could accept or even encourage? Well yeah, I never want to discourage passion. If they knock off early the next day to get some well earned rest I’m all for that too. But is this passion hiding a more worrying truth? I see devs working late because they know the’re heading down a path that the rest of the team would freak at, but they’ve invested so much in it they don’t want to stop. When the guy or gal staying late doesn’t want to tell you why, it’s time to suggest the pub or attending a local meetup group might be a better alternative. So yeah I’m comfortable with people working out of hours if it’s because they’re passionate about what they’re doing. I worked with one dev who would work on experiments whilst his wife watched EastEnders. He’d join us the next morning excited about what he had to show. But it was always an experiment and we’d usually sit down together and re-write before committing it. Work done for the team should be done with the team.