I am trying to find a specific kind of iOS application. I am using the App Store in iTunes, on a Macbook Pro with a 27″ external monitor, extended keyboard, and wireless mouse. But it doesn’t really matter. I could be on my ipad, and the experience would be just as frustrating. Apple says that they have 500,000 apps available for iOS. This is a big point of pride for Apple. Well let’s look at all the tools Apple gives iOS users to navigate 500,000 Apps to find what they want.
I would like to find a keyboard utility the can replace the iPad software keyboard with one that has arrow keys for editing and is more accurate. I don’t know if such a utility exists, however the keyboard and text editing capabilities of the iPad are a regular user complaint. I open iTunes and click on iTunes Store and then the app store. See the screen shot below. I am confronted with a giant rotating advertising banner that often features Apple products like ibooks 2 and iTunes U. Scanning the rest of the page I see headings New and Noteworthy, and Quicklinks, this section includes additional lists featuring Apps chosen by Apple.
The Apple App Store Front
On the right there is a “Top Charts” list featuring more Apps that are the top of some metric, also controlled by Apple. Other Navigation headings include the enlightening “What’s Hot” section, featuring another Apple controlled list of Apps. Scrolling down the page are 7 more lists defined by Apple staff.
Futile Browsing
What if you know generally what kind of App you want? Well out of the whole first page of the App Store, there is only one small button that might take you to where you want to go. Under Quicklinks is a dropdown list with broad categories. How long do you think it would take for most users to find this single button with its hidden categories? Well, they probably wouldn’t. I did, because I am writing this article and went over the App Store’s front page very carefully. Clicking on the drop down I am confronted with a long list in very small font, of all the categories. After a couple tries I click on the category Utilities.
iPad Utilities Landing page. No further categories, more Apple controlled lists. Click image to see UI detail.
The Utilities page loads more Apple lists, with New and What’s Hot again listing Apps that Apple has chosen to feature. This is the end of the category navigation. Only after scrolling down do we find the All Utilities iPad Apps section. The section has 3960 applications, of which we can see the first 24 with listed with “most recently released” at the top.
App Store Ipad Utilities page, 3960 Apps
To find a keyboard I re-order the list and click on “K-O” since I am looking for a keyboard utility. iTunes returns 180 applications from App iXML to LogVu. I find 2 Apps with the first word Keyboard. After viewing an App I click the Back button, however the list is different and I am disoriented. The 3960 Apps are reordered by release date again and I am back on the first page. After multiple tries I give up on browsing. However there are likely other keyboard utilities that use different names, so I will try another approach.
Searching for Something?
ITunes has a global search feature in the top right of the application. searching “keyboard” in this search utility returns results from movies, music and every other section of the iTunes store. Filtering by Apps, and then again by iPad Apps returns all iPad Apps for “keyboard” a whopping 581 entries, all conveniently sorted by well, actually I cannot determine how they are sorted, and I can’t change the sort. My search for a keyboard utility has returned Apps from almost every category, including Utilities. More specific search terms, such as “keyboard utility” or “keypad” or “arrow keys” returned more specific results, including everything from emoticon Apps to remote controls for PC and Mac applications. Apparently it is easier to turn the iPad into a keyboard for a PC application then it is to create a different keyboard for the iPad itself.
Searching returns long unordered lists with no descriptions
Power Search: Did you Miss it? I did.
In doing the search I stumbled upon the Power Search feature. Power Search allows you to select a more detailed search criteria. Where do you find it? Well that’s a good question as power search appears and disappears from the App Store UI, even while you use it. It also doesn’t seem work, missing some Apps, or returning Apps not in the category selected.
Too little information
As can been seen in the figure above, search results include a picture, the title of the application, the date it was updated and the price. There is literally no way to judge whether an App is worth your time unless you click on it and view the application’s page. Even on this page critical information about the App is hidden from view on the App’s own page, Users are forced to click again to read more than the first 2 lines of the App’s description.
Useful information is hidden from users on the App's own page
Your App is lost in the App Store
App developers should be very concerned about How Apple is controlling access to their applications. By not building in effective browsing and search features, Apple is preventing customers finding your application. This means all the time, effort, and money spent on your App is wasted, since unless the marketers running the App Store choose to promote your App in the Apple controlled lists, potential customers can’t find your product.
A lesson from Amazon and Musician’s Friend
Apple customers and iOS Developers both lose with Apple’s App Store User Interface. Navigating the App Store is painful, slow, and ineffective. It is clear that the App Store in iTunes was never designed to handle an inventory of 500,000 Apps. The App Store and the other storefronts in iTunes need a major investment to bring them up to the ecommerce standards of today. Instead of providing effective tools that allow users to find the Apps they need, Apple is pushing dozens of lists, in the hope that Apple taste makers know what Apps their customers want. This is bad for the App market, bad for App developers, and very bad for App Store customers. Apple needs to take a lesson from ecommerce sites such as Musician’s Friend and Amazon. Those sites handle as many or more products then the App Store and they provide the tools users need to find the products they want. App store users, whether on the PC, iPad or iPhone need to be able to browse and search effectively to find the Apps they need. Today the App Store is a little shop of horrors to use, devouring both customer’s and developer’s time and money. I still have not found that keyboard utility to replace Apple’s iPad keyboard, so I will continue to reach for the laptop and leave the emails for the Android powered Motorola Droid Pro World phone with its real keyboard.
This is a video of a talk I gave at Agile Tour 2011 in Vilnius Lithuania in October 2011.
Your New Customer has no clue what Agile is, however they have lots of assumptions about how they will “get the product done.” Do they know how to work effectively with you? Do they know all of the business and user issues that the product will need to solve and how to solve them? Have they built a product like this one before? Are the 100% committed to being the product owner or do they have other jobs too?
We’ll discuss how turn a customer into a Product Owner, from the first meeting to creating the first backlog, through to one year into development. We’ll go through key learning points that your new Product Owners and teams will have to transition through, and techniques you can use to make your life and theirs easier. Come prepared to learn tested hands on techniques you can apply in working with your customers.
I just taught a course and participated in a software conference in Vilnius Lithuania. Over the last 3 years I have taught Scrum to over 800 software development staff in the Ukraine, and hundreds more in the US and Brazil. The situation is much more complicated then you portray, and not as negative as the article implies for US/EU workers. The huge missing piece in this article is VALUE. The perspective presented is only focused on cost. It is about the same as saying if only there were lower taxes the US job market would improve. This is false thinking, and surprising from an investor. Why do we invest? Because of the potential opportunity. For example take the team of A players tweaking the Linux kernel yet again, and compare them to the B players who develop a hugely popular web site like gamespot. Which team generates more value? Another missed point is the huge demand for software. Unemployment in the US IT sector is 3.2%, compared to over 10% in other sectors. A more recent phenomena is companies who outsourced all development now rehiring developers because of communication, speed and quality problems. Capital One and Wells Fargo are examples.
By far the largest problem in software development is management. Managers who learn how to build and nuture lean and agile organizations will create organizations able to respond much more quickly to the market while growing the strength of their teams. This is where many companies fail miserably, and generate huge amounts of waste in failed projects, burned out staff and unmet expectations. There are no lean and agile organizations in our industry today.
Toyota became the largest and most profitable car company with staff from all over the world. They did it because the Toyota Production System is unmatched in terms of creating successful results. This is a management system and a way of viewing the world of work. Whether the cars are built in Manila or Kentucky, the driving force for success is not the cost of labor.
“I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?”
Dr. Eliyahu M. Goldratt 1947- 2011
When I first read Eli Goldratt’s book The Goal, it was in 2005. I had been using XP and Scrum for 3 years and understood the value of good process improvement ideas. I was stunned after reading it. Not only was the book fantastic, I was shocked: this book had been written in 1986?!?! I felt embarrassed that I had never known about these ideas. In 1986 I was still in engineering and these ideas were cutting edge at that time. Is Theory of Constraints taught in engineering schools 25 years years later? A search of goldrattschools.org reveals 9 affiliated universities, and google searches are not filled with education institutions teaching Theory of Constraints (TOC). It seems most people learn about Theory of Constraints through direct efforts of Goldratt’s various institutes, the Goal and subsequent books, and word of mouth. I have told many people about and given away copies of the Goal, creating numerous converts to Theory of Constraints thinking. Goldratt’s ideas provided many insights into systems thinking and process improvement. As a software development manager who had already transitioned from more traditional management to Scrum and Extreme programming, I found TOC provided another set of thinking tools to analyze a work system. These tools complimented Lean and Agile without reducing their value or conflicting with those ideas. For example Theory of Constraints provides a way to prioritize process changes found using Lean tools or impediments found by the team using Scrum. However the biggest change was that TOC made me think differently. It changed my perspective on systems, on software development and work in general. Like Lean thinking, TOC colors my thinking about any system and gives me greater insight into the natural properties of systems.
Ours and future generations are indebted to Goldratt’s ideas and his insights into people and systems. His ability to write about these ideas using non-technical stories was almost as important as the ideas themselves. His writing allowed many people to pickup his books and within a few hours understand the core concepts of Theory of Constraints. The appeal of TOC ideas caused them to look for ways to apply TOC to their work, while his easy and accessible style created powerful incentives for people to learn more.
I am truly sorry to hear that a genius such as Eli Goldratt has passed away at the relatively young age of 64. I am grateful to have been a student of his ideas and hope to carry on the work of spreading the ideas of TOC and its applications in software development and knowledge work.
Dr. Eliyahu M. Goldratt spent his entire adult life fighting to show that it is possible to make this world a better place. We must have the honesty to see reality as it is, we must have the courage to challenge assumptions, and above all, we must use the gift of thinking. Having applied these principles to various management fields, he created the Theory of Constraints. His concepts and teachings have expanded beyond management and are being used in healthcare, education, counseling, government, agriculture and personal growth – to name a few fields using TOC. His legacy is invaluable. On June 11th, 2011 at noon, Eli Goldratt passed away at his home in Israel in company of his family and close friends.
The strength and passion of Eli allowed him to spend his last days sharing and delivering his latest insights and breakthroughs to a group of people who have committed to transfer this knowledge to the TOC Community during the upcoming Theory of Constraints International Certification Organization Conference in New York. It was Eli’s last wish to take TOC to the next level – truly standing on the shoulders of the Giant he is.
A recent discussion on linkedin was started based on the question: Should teams talk directly with users or customers?
It provoked me to write the long response below.
“What do you mean by customer? Do you mean user? Sponsor? Another manager?
The Product Owner (PO) should be representing the various stakeholders for the system being built. The PO should also be creating alignment among the team and the stakeholders as to what needs to be accomplished in the release. This is a balancing act between the various needs, business and technical. The PO is not an information hub, everything doesn’t have to go through the PO. A good PO creates alignment around the vision and the solution, and steers based on their ongoing learning and subject matter expertise.
So I’d split my response into the stakeholder groups:
For users:
In general it is a good idea for a Scrum team members to talk to users. As Geir Amjso mentioned, the PO can become a bottleneck if they try to control all information. Also their maybe some nuance that a user can provide that will help a developer understand the problem more clearly. This conversation is framed in the context of a sprint and is about clarification and understanding to implement the solution.
Another benefit of having users and developers interact is that spark of innovation. Innovation happens when people with tools and techniques really start to understand a problem. Users sitting down with developers creates empathy and helps teams become motivated to provide pain relief or innovations that surprise or delight.
For sponsors:
Not a good idea without the PO around. The sponsor is usually more concerned with the high level issues and the politics/expectation management for the product/project. The sponsors should engage the PO, and if they are going around them to the team, there is something else going on.
For other managers:
It depends. It may make sense if there are dependencies with other teams/vendors and the team is managing those issues within the sprint. It may also be an end run around the PO to get work done that is not planned in the sprint. In this case the team should refer them to the PO.
Scrum does specify meetings where interactions between teams and customers are more formal. However Scrum says nothing about restricting communications to the Scrum meetings. If communications are restricted to these meetings only the team will be slower and have less opportunities to learn. As a Scrummaster the goal is to get great software developed and do it with the highest level of engagement from all parties. This means there are lots of communications that should happen on an ongoing basis between all members of the project community. A Scrummaster needs to enable work to flow from request to working software, and this involves maintaining the flow of information. Will their be deviation? Sure, however the Scrummaster is there to detect when the team or the stakeholders are getting off track (i.e. adding scope, changing direction, etc.) and help them stay on track.
In September 2010 I gave a keynote talk at Agile Eastern Europe called “Dude, where’s my backlog?” The talk covers the common pitfalls seen with Product Owners and the Product Backlog. The talk covers the people that bring a product backlog into existence and the processes they can use to maintain it. This includes using ideas from Kanban for personal process and modifications to Scrum for more frequent involvement of the team in maintaining the backlog.
QSystem: realtime 3D audio for recording applications
In 1990 we created QSystem, the first 3D audio system for professional audio recording applications. The system was used by Sting, Madonna, Roger Waters, Pink Floyd, and many other artists in the recording studio. Unlike surround sound systems today, this system created audio for playback on 2 speakers. The sound was positioned using filters that tricked the mind into perceiving the sound came from beyond the stereo speakers. The version 1.0 and 1.1 of the system had 8 channels of position processing, and the locations were fixed in a 180 degree arc. In QSystem version 2, pictured above, we wanted to add the ability to control the position of any channel with a joystick, and to record joystick motion so that positioning would be played back with the recording. This meant a completely new user interface, a custom joystick, many new system software features (C++ on DOS) for handling the joystick, recording, and interfacing with the studio automation system, and changing the core audio digital signal processing architecture code that ran on the Digital Signal Processors (DSPs). We also designed a new DSP processor board at the same time. All this with less than 10 people.
The User Interface challenges were significant. We had a system whose primary purpose was audio output. We had to provide a real time graphics display for positional information of each channel, but this was DOS on a 386 and CPU was needed for audio processing control. The processing that did the audio positioning was non-linear and constrained the movement paths within the semicircle shaped sound field. We also had a lot of uncertainty since there was no product like this on the market. When faced with a problem like this we had the benefit of beginner’s mind. We had no idea what was going to work, so we started trying things and kept it simple. I worked on the DSP algorithm, looking for a way to smoothly control audio with a joystick. An industrial designer worked on the joystick case. Our best programmer tackled the joystick recording, playback, and synchronization features.
Some stakeholders drew complicated 3D pictures of how the UI should look, including the founder. Many discussions ensued where we had to explain that we could not commit to such a design until we knew more. As we built up the features, we created a simple 2D map of the speakers and semi circle sound field. The position of the joystick was a dot on this map. As we played with the UI we found that the sound position was not reflected correctly in the UI, so we changed the parameters controlled by the joystick to improve the auditory realism. Once this was working the recording and playback features were added to the system, again the UI was simple, driven mostly by the buttons on the joystick.
While we were working on the system others searched for alternative displays to a bulky PC CRT monitor. The CRT was heavy, not very rugged, and as we discovered with QSystem v1 they caused shipping problems. Late in development the team found an industrial display that met all our system needs, however it was a monochrome LCD. We tried it out and it worked great. Because we had not invested time in a complicated interface we were able to make this robust but simple display work easily.
During testing in the studio the founder and others who had initially wanted the complicated interface got a chance to use the system for hours. In use they found the interface’s simple design was more than enough. They liked the way it focused the attention on the audio instead of the screen. With most of the functions controlled by the joystick, the sound engineer could forget the display and focus on the sound. In later revisions we made some improvements based on feedback. The complicated 3D interface came up a few times and we thought how misguided an idea it seemed knowing what we now knew.
We were successful in solving a complicated UI problem in an elegant way by moving the technology and UI forward together. The technology imposed constraints on the UI, changing our initial design ideas. The joystick made us rethink how to control the system to make it easier to use. The late arrival of a major UI change, the monochrome LCD, did not cause major changes to the UI since we had kept things simple. A complicated graphics intensive UI was strongly advocated in the early phases of the project however it turns out that it would have been a disadvantage in effort/cost to implement, cost of CPU resources, and would not have worked on the monochrome LCD. Locking in complicated UI design upfront would have significantly increased the risk of failure and delays in this project. By focusing on simple solutions as the underlying system was developed, we arrived at a solution that was simple to use, task focused, and flexible.
I was a technology Director in a large web design company 6 years ago, and they failed to adopt Scrum. There were numerous management dysfunctions, however the Creative managers were the most resistant. Primarily it was a case of not wanting reality to hinder the pretty designs they were making in Photoshop or Illustrator with the reality of building enterprise software. Of course there were huge issues when these artifacts met the reality of enterprise architectures on the development floor. This dysfunction resulted in missed deadlines, high stress, low code quality, and 40% annual turnover in IT staff (and pretty graphics). Being at this company spurred my interest in UX and Agile, and I have since found basic solutions that work when people want to do Agile. To date I would say that of all the disciplines in creating software and especially web sites, UX people are the slowest and most resistant to adopting Agile principles and practices.
Here is the way I work with UI Designers and Information Architects who want to work Agile:
1. Product backlog and its priorities drives all the work. So we work from business priorities not UI priorities.
2. Sketch the highest level level UI for the site. No drill downs into buy flows, just top level.
3. Look at the backlog and start thinking about what the team will need for UI 1/2 an iteration ahead.
4. Make paper prototypes (sketches, paper menus, paper buttons) to support upcoming user stories for next sprint. Don’t embellish with new features UX thinks would be cool. KISS. Include validation and other acceptance criteria for fields. Reference style guide as required. Reference page templates as required. I call this a 1 page design spec.
5. Review prototypes with PO, QA and lead dev a few days before sprint planning, ensure they think it is good enough and it is testable. Keep notes regarding potential trade offs.
5a. Check in design docs, version them.
6. Participate in sprint planing with rest of team.
7. Work with team on implementation, clarify details of design (dimensions, locations, behavior, etc.). Work with QA on test plans for new UI. Help build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up. Pair with QA to run test cases and implement automated UI testing (Ruby/WATIR, etc).
8. repeat for every sprint.
To recap the UI designer starts 1/2 sprint ahead of the team, helps the Product Owner with UI issues, and creates very lightweight and flexible prototypes as input to sprint planning. The rest of the work is done within the sprint. I have found this is “just enough” lead time to have thought through UI issues without creating solutions in a vacuum away from the team.
Additional tactics to include:
Create a style guide for the team and have them read it, listen to their feedback and improve it.
Create templates: every page is not a unique creation. Refer to those templates in prototypes and design spec.
Break dependencies between UI/layout and business logic at beginning of the iteration. Agree on data/fields/controls at beginning so business logic can be rendered to a very simple layout free page.
Test your paper prototypes with users by asking them to do certain operations and then observing the resulting actions. Don’t worry about big usability testing at end, do it often and informally with people who are easy to access and know enough about that business.
AVOID COMPLEX HIGH FIDELITY USER INTERFACE DESIGN TOOLS. They really slow you down and lock in decisions far too early. These decision are often wrong.
The root cause of an unstable UI design is usually a lack of detailed knowledge about the customer requirements and technical limitations. The product backlog and its user stories and acceptance criteria are probably not in very good shape. To cover these gaps the UI person has to go find out a lot of detail to create the design, which slows them down and results in numerous design changes during the sprint. The UI designer is likely having to make up for lack of knowledge or lack of effort on the part of the Product Owner. Fix this root cause by getting the Product Owner to improve the product backlog so the designer and the team have better user stories and acceptance criteria coming into the sprint. User Interface work is simply another form of software requirement, as are software architecture, features, and test plans. All of these activities can be done in a “just in time” and emergent fashion and result in consistent architectures and usable interfaces. Many are doing it today. However it does require people to change their behavior, and that is likely the hardest thing to do.
Over the last 2 years we’ve seen some pretty hard times in economies in Europe and especially the USA. Financial services and lending business were in an state of near collapse. With each day companies were announcing job cuts. Job losses in the US are higher than they have been in 30 years. Now that the economy has stopped shrinking, and markets are starting to improve, companies are facing a much more difficult business situation. Stock prices and profits have recovered in some sectors, however most companies face slow growth, and systemic changes in their marketplaces. The US consumer has lost a substantial amount of net worth. That group is not coming roaring back to consume like they have in the past. Many of the businesses that cut staff will not be hiring them back, either because they don’t need the capacity, are doing something different, or are out of business.
Many State and local governments are facing heavy shortfalls in revenue. One important reason for declining tax revenue is property taxes. Property taxes are hard to collect when the property is in foreclosure. Commercial properties are also strapped as their clients break leases or only make limited payments. These losses often result in commercial property owners going out of business. The commercial property failures significantly lag consumer mortgage foreclosures, since commercial properties are not affected until their clients start going out of business. Booming government deficits, high unemployment, slow growth, and increased competition in a global marketplace.
As bad as the economy is now, I am sure it is not as bad as Japan’s collapsed economy just after World War Two. That is when Toyota decided to enter the automotive business. 60 years later Toyota leads the industry by most benchmarks, and are more profitable then the next 4 automotive companies combined. During this recession GM and Chrysler collapsed, and all three big auto companies required billions of taxpayer dollars just to survive as much smaller companies. At the same time Toyota took thousands of idled workers and launched retraining programs so they would be ready for the next generation of manufacturing, new assembly systems, and upcoming products.
The great recession of 2008/9 was bad for airlines, many shrank 10 to 15% and some went bankrupt. During this same recession Southwest Airlines managed to grow by 1%, while paying its pilots more than any other US Carrier. Southwest has been profitable for 36 years straight.
There is a major story that is being completely overlooked by the American Media. That story is how some companies have found a way to gain not one or two years of competitive advantage, but 10-20 years competitive advantage. How some companies consistently innovate and thrive, while others consistently fail to meet the expectations of their customers, employees, investors, and the public. These under-performing companies may have survived the recession, however unlike GM and the banks, there is no bailout coming from cash strapped governments to save them.
What do successful companies like Toyota and Southwest airlines do differently? Can they provide a road map for other organizations? What stopped GM from changing and how to recognize those patterns in other companies?
The New York Times and Wall Street Journal are missing the boat for their readers. There is an important story that European and American business leaders are largely clueless on. I know because of the conversations I have with their VPs, managers and staff. The executives running those companies have a fiduciary duty to get up to speed and start to redesign their organizations so that their companies stop surviving and start thriving.
I recently read a great post by Cary Millsap, an influential member of the Oracle community on Oracle and Agile. I have read both of the books Cary mentioned, they are excellent, and the Goal by Eli Goldratt is outstanding, if you haven’t read it, put it at the top of your list. It is a novel and has nothing to do with software.
I don’t really understand why Agile is not embraced by the Oracle community. There are lots of reasons why it can make a developer’s life better, and it doesn’t matter whether it is coding SQL or Java. However from a DBA perspective, I think having changes committed to production DBs every week or two is scary, especially if you are the one carrying the pager and responding to 4 AM outages (and why do they seem to mostly occur at 4 am?).
For Agile to be successful we need to deploy early and often. For production stability and performance we need to quantitatively know deployments are going to work just as well or better than the last deployment. There need to be safeguards put in place to address the risks, and systems that reduce or eliminate the transaction costs of doing deployments. As mentioned in Cary’s post, automated testing plays a huge role here.
Here’s one way of stating the DBA’s needs in the form of a user story:
As a DBA I want to have a stable, high quality database to monitor performance and tune so that I can maintain data operations and improve system performance.
Acceptance Criteria:
New database releases to production must contain all the performance improvements implemented in production to date.
All DB changes must have automated test coverage that quantify whether or not the DB changes implement the desire inputs and outputs correctly
Any DB change found to not function correctly can be rolled back without impacting the rest of the DB
All changes between production deployments are automatically calculated and displayed to DBAs
Production Databases are stable and not changing between the regular release cycle.
DBAs collaborate with and are consulted by the team(s) implementing DB changes
DBAs provide weekly mentoring and DB code reviews with team members implementing changes
(Please add your additional acceptance criteria)
What changes you would need to implement in your organization so that the above user story were true?
If you are a DBA working in a small company next to developers and QA, then maybe it is changing a few of your practices, working more closely with the other developers on DB changes, implementing test frameworks like DB Unit, getting SQL code into version control, implementing a DB change management tool like Liquibase, and creating a better rollback strategy.
If you are in a large bank sitting with 15 other DBAs at the backend of a manually intensive, form driven, cost managed, outsourced deployment process, you have some work to do . The goal and many of the steps are the same as with the small company. Ironically, the bank has many more resources to implement these changes. However the management hierarchy and organizational silos make it much slower and more difficult to implement these changes. So what do you do? Well you can continue to stay in your DB team silo, complain that Agile is the problem and be the victim. This means that most interactions with others wanting changes will be negative, you will be viewed as obstructionist, and that cute tester will think you’re a jerk. Another approach would be to remember that we are all on the same team, and go for a walk and meet the Agile teams to see how you can work together. You might take this blog and the user story above, show it to the ScrumMaster, Product Owner and Developers. Start a friendly discussion about how your needs for a reliable, production friendly DB can be met in the context of regular production releases. Remember that by doing this you are asking them to change as well, and since you are both changing, the situation becomes problem solving together. One more point, expect mistakes to be made and occasional firefighting on the road to a more effective development and database operations process. The changes are non-trivial, the results can be amazing, and the journey is the most memorable part of the experience. Bon Voyage!
Thanks to James Thomson for the inspiration on this one.
This 2 day course covers how to use Scrum to manage your Agile projects. Students gain an understanding of Agile principles, Scrum practices, and how to manage the Scrum process. Recommended for project managers, technical managers, and technical leads.
Current classes are listed on the Scrum Training site.
This 2 day immersive training is great for teams who are looking to adopt Agile for their project. Team members come away with a solid understanding of how to work day to day on an Agile project, how it changes their role and what they should expect. It covers Lean, Agile, and Scrum, with a focus on the Scrum project framework.
Many State and local governments are 
. The goal and many of the steps are the same as with the small company. Ironically, the bank has many more resources to implement these changes. However the management hierarchy and organizational silos make it much slower and more difficult to implement these changes. So what do you do? Well you can continue to stay in your DB team silo, complain that Agile is the problem and be the victim. This means that most interactions with others wanting changes will be negative, you will be viewed as obstructionist, and that cute tester will think you’re a jerk. Another approach would be to remember that we are all on the same team, and go for a walk and meet the Agile teams to see how you can work together. You might take this blog and the user story above, show it to the ScrumMaster, Product Owner and Developers. Start a friendly discussion about how your needs for a reliable, production friendly DB can be met in the context of regular production releases. Remember that by doing this you are asking them to change as well, and since you are both changing, the situation becomes problem solving together. One more point, expect mistakes to be made and occasional firefighting on the road to a more effective development and database operations process. The changes are non-trivial, the results can be amazing, and the journey is the most memorable part of the experience. Bon Voyage!